Add block additional mapping for generic type/value

[dericed]

This is based upon the timecode branch, but this offers a generic key/value structure for side data. For discussion.

[mbunkus]

If I understand this PR correctly, there would not be a way to associate more than a single key/value pair with each frame. That I definitely don't like.

Additionally we don't have a way of associating a BlockMore with a certain frame inside the BlockGroup. Either we add one (via a new frame-number-in-block element inside BlockMore), or we mention explicitly that a BlockMore applies to all frames in the BlockGroup's Block, and that writers that want to associate the BlockMore with a specific frame only would need to limit the number of frames in the Block to 1. Or we could spec that the BlockMore is always associated with the first frame only.

[mkver]

In FFmpeg packets can have AV_PKT_DATA_STRINGS_METADATA side data, a list of zero terminated key/value strings. The whole side data is externally framed. Putting such a thing (or something similar; i.e. the strings could be length-prefixed (probably with EBML numbers)) in a BlockAdditional would overcome the restriction to a single key-value pair; but it would have the downside that key would have to repeated every time.

Another way to overcome this restriction would be to allow several BlockAdditionalMappings with the same BlockAddIDType, but different BlockAddIDValue. Each of these would have its own key.

[robUx4]

IMO the FFmpeg usage sounds like the "key/value" type is too broad. It's a way to store the data, but it doesn't say what the data correspond to. There might be different systems using the same key.

It should be a BlockAddIDType per usage (one would be for FFmpeg) and then saying it's using key/value storage.

[robUx4]

Rebased so it can be used. (SMPTE ST 12-1 has been merged)

[robUx4]

Rebased on top of #936 to simplify.

There is nothing is the spec that says the same BlockAddType can't be used multiple times in the same BlockGroup so this seems OK to me.

There's still the caveat that it's loosely defined and not very useful to interpret.

[robUx4]

Moving this to Matroska v5 as this is not used yet (or in Rawcooked ?). (if it's merged before we finalize the codec document, it's fine).