Add a BlockAdditionMapping name

[JeromeMartinez]

Add something similar to \Segment\Tracks\TrackEntry\Name.
While trying to change \Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName definition, I remarked that this block is too much defined with a specific value in other parts of Matroska specs (it should also be utf-8 and not non utf-8 string), so I switched to a new block identifier. This would also avoid to have an errata for this update.

[robUx4]

No sure what you mean by "too much defined with a specific value in other parts of Matroska specs". It's an optional value that is used to have a human friendly name. That element was added in #287 with the other BlockAdditionMapping element. I wonder why I used a string rather than a utf-8 type. It was supposed to mimick the CodecName, which is utf-8.

I'm OK with adding the new (better) element. But it should deprecate the other one or mention it has prority over the old one. Like we do we BCP47 language elements:

If this element is used, then any Language elements used in the same TrackEntry MUST be ignored.

[JeromeMartinez]

But it should deprecate the other one or mention it has prority over the old one.

As far as I understand, BlockAddIDName is for describing the type (e.g. "this is a timecode track"), not for describing the content (e.g. "this comes from VITC") which is my goal with this new element, it is an addition so no deprecation.

No sure what you mean by "too much defined with a specific value in other parts of Matroska specs"

I was thinking to change the definition of BlockAddIDName because in practice it is not really used, but changing at the type of the element is maybe too much, so using another element id is maybe better.

[robUx4]

As far as I understand, BlockAddIDName is for describing the type (e.g. "this is a timecode track"), not for describing the content (e.g. "this comes from VITC") which is my goal with this new element, it is an addition so no deprecation.

Indeed, the main difference in the definition is "type" versus "name". But we usually only put things in Tracks that are necessary for the proper playback or user identification. What you want seem to go rather in Tags which could have many descriptions in many languages. And this is possible now with the TagBlockAddIDValue in v5 tags.

If you need information that are necessary for the proper processing of the additional data (this is from VTIC so it works this way and not that way) that should either go in a BlockAddIDExtraData element, use a different BlockAddIDType to distinguish each flavor, or add a more typed element to distinguish them. I think the BlockAddIDExtraData is the cleaner option here.

[JeromeMartinez]

As discussed during IETF meeting, I'll change this PR to define tags and provide a list of "sources" vocabulary.