[Cellar] Experimental elements

[Steve Lhomme <[e-mail]>]

As discussed in
https://github.com/Matroska-Org/ebml-specification/issues/157 We need
a clean way to define experimental elements. So that new elements can
be added/tested while not having to iterate the DocType version each
time. Especially as the they are meant to be backward compatible as
much as possible.

I added to proposal on GitHub:
- https://github.com/Matroska-Org/ebml-specification/pull/180 a simple
DocType sub-version that allows iteration between different versions
before new elements are finalized in a new DocTypeVersion.

- https://github.com/Matroska-Org/ebml-specification/pull/181 a list
of DocTypeExtension which allow different groups to work on different
subsets of elements, each with their own name (or workgroup or
namespace).

In any case elements from each proposal don't have to be handled so
long as the EBML Reader can handle the DocTypeReadVersion. But if they
can, it's nice.

Following this concept, I wonder if Tags could exist as a Matroska
Extension, possibly not part of the main DocTypeVersion at all.

Jerome wanted some extra elements, this could be done this way as well
in a clean way.

Note that an extension version depends on the DocTypeVersion it's in.
So moving from matroska v4 to matroska v5, each "independent"
extension should have an update if they want to keep working. Or we
could not do that at all and allow extensions having a life of their
own. Maybe there could be 2 types of extensions: those which goal is
to be merged in the main DocTypeVersion, those standalone.

The DivX elements are good examples of extensions that could leave on
their own. And we wouldn't have to put them in the main spec and
wonder how they could work. On the other hand these old files don't
advertise this extension...

-- 
Steve Lhomme
Matroska association Chairman