[Proposal] Add type value to "tag" command

[ratmice]

This is a proposal to modify the accepted proposal for a tag command to include a type value. Tag currently is specified as containing just a length, and a data blob.

command-name:  "tag"
command-index: 11
layout:
  length: varuint
  data:   [length]u8

There are two reasons for this proposal:

1. type tagging must currently be done in the data, requiring producers and consumers to encode/decode data types.
2. When producers can invent random blob formats, it is difficult to ensure that the formats can be unambiguously detected without conflicting with one another.

This proposal would modify the layout of the tag proposal to include a value type: varuint, and add one new command, for
declaring extension points

command-name:  "tag"
command-index: ...
layout:
  type: varuint
  length: varuint
  data:   [length]u8

command-name:  "extension_point"
command-index: ...
layout:
  type_addr: varuint
  length: varuint
  extension_name:   [length]u8

The extension_point command is defined to use a relative type assignment scheme for assigning type values to tag commands.

Each extension is responsible documents a range of values from 0 up to some static size which must be less than that which fit within a varuint (32).

file writers are responsible for assigning the extension_point a type_addr. such type_addr + 0 can be used for the first type value documented by the extension. The producer must ensure that type_addr + maximum_range documented by the extension point in it's specification is less than the maximum size of a varuint.

As such if an extension declares the complete range of varuint as reserved that extension is not compatible with any other extensions. It is not the intent of this scheme to facilitate extensions that are inherently incompatible in this way. Extensions are suggested to reserve the minimum range of types necessary to ensure their task (perhaps reserving unused types for future expansion).

Benefits of this kind of scheme:

1. data values that both carry additional data, and assign command identifiers are easier to parse, since we do not need to encode both the data and the type value within one data value.
2. While the extension_name field is not burdened with both
   being a unique discriminant value for identifying both command type as well as a data carrying value.
3. It is no longer necessary for Extensions and file readers ensure that their chosen tag data value encoding schemes are globally unambiguous with all other tinyvg file producers that encode extension tags. Just that producers assign type_addrs divying up the type space appropriately, and encode type values using the correct offsets (assigned by the extension) from the type_addr they specified.

This feels to me like it's a workable type assignment scheme,
which given unique extension names, could work freely of centralized tag encoding lists.

Impetus:
I wanted to work on something defining two sets of tags,
the first is similar to the optional content groups defining layers which can be toggled on and off.

Secondly, encoding additional datatypes like those defined by georeferenced pdf such as coordinate space data formats.
Both of these values if ignored should produce a valid tinyvg file. If we ignore layers, they just can't be toggled on and off, and the layers are all flattened.

If we ignore georeferencing data, the file just won't correlate with gps data, etc. So these are still valid tinyvg files.

But without a scheme like this there is still some risk that arbitrary producers of tag schemes clash with one another, such that we cannot differentiate our extensions apart from malformed data encoding.