allow TrackTimestampScale in Matroska v4

[robUx4]

Following the investigation in #422 it seems like a good tool to achieve sample accurate timestamp in many (more) cases.

In posts starting from #422 (comment)

[robUx4]

@mbunkus any opinion on that ? It seems libmatroska is not ready for that move but it's possible to work around it without breaking everything. That has a direct impact on support for this feature in VLC as well.

I have patches for libmatroska, VLC and libavformat (read and write). So it's at least possible to use it (with sample "accurate" timestamps, see #425). It should not be used by default because most existing readers, if not all, will not handle the value properly. But it can gradually be added. After all it's something that should have been supported since the beginning. And it is there in the specs up to version 3.

[robUx4]

For the record, the feature is now available in libavformat for reading. For writing it depends on codec packing size(s) so we need a list of known packing sizes (in my test to generate files I used 8 by default which should give long enough Clusters in most cases).

[robUx4]

This is necessary but not sufficient to do sample accurate timestamps. For that we also need proper #439 documentation.

[robUx4]

Turned into a draft until #521 is merged.

This now contains the formula to use TrackTimestampScale to get the Track ticks matching the sample number of each track.

[robUx4]

The consensus on #422 is that reusing the element with some extra trick will likely not bring real world support. So it should be done with new elements instead.

Therefore I'm closing this, but parts could be reused to describe properly these elements.