feat: adding MIME types as codecs

[bochaco]

Resolves #4
Each MIME type is added as a codec which codec name is prefixed with 'mime/' as suggested in this post, i.e.:

mime/<mime-type-here>

Based on the information at 1 the following ranges are reserved for any mime types/sub-types:

Range 0x1000 - 0x17ff: (11 bits) reserved for 'application/*' (there currently are ~1,300 subtypes)
Range 0x1800 - 0x18ff:  (8 bits) reserved for 'audio/*' (there currently are ~150 subtypes)
Range 0x1900 - 0x190f:  (4 bits) reserved for 'font/*' (there currently are ~8 subtypes)
Range 0x1910 - 0x197f:  (7 bits) reserved for 'image/*' (there currently are ~60 subtypes)
Range 0x1980 - 0x19cf:  (5 bits) reserved for 'message/*' (there currently are ~18 subtypes)
Range 0x19d0 - 0x1a3f:  (6 bits) reserved for 'model/*' (there currently are ~24 subtypes)
Range 0x1a40 - 0x1a8f:  (5 bits) reserved for 'multipart/*' (there currently are ~13 subtypes)
Range 0x1a90 - 0x1aff:  (7 bits) reserved for 'text/*' (there currently are ~71 subtypes)
Range 0x1b00 - 0x1b6f:  (7 bits) reserved for 'video/*' (there currently are ~78 subtypes)

In this PR only the MIME types listed at 2 are declared since these should be the most relevant for the web, plus a few additional ones useful for the semantic web.

[1] : https://www.iana.org/assignments/media-types/media-types.xhtml
[2] : https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types

[ghost]

Oops, I accidentally commented in the other issue: #4 (comment)

[bochaco]

That's fine @lgierth , we can continue the discussion in issue #4 to agree on how we want this first addition for MIME types, I just replied there.

[hacdias]

Ping @vmx @lgierth

[vmx]

@Stebalien is currently kind of the gatekeeper of the multicodecs. Do you know what plan in regards to mime types is?

[Stebalien]

1. That's going to use up ~20% of the two byte range. What if we allocate from either the 3 byte range or the 4 byte range? 4 bytes to indicate MIME types isn't really that expensive.
2. IMO, we should over-allocate for each sub-type so we have plenty of room to expand.

So, we could allocate the range 0x200000-0x280000:

Range 0x200000 - 0x20ffff: reserved for 'application/*' (there currently are ~1,300 subtypes)
Range 0x210000 - 0x21ffff: reserved for 'audio/*' (there currently are ~150 subtypes)
Range 0x220000 - 0x22ffff: reserved for 'font/*' (there currently are ~8 subtypes)
Range 0x230000 - 0x23ffff: reserved for 'image/*' (there currently are ~60 subtypes)
Range 0x240000 - 0x24ffff: reserved for 'message/*' (there currently are ~18 subtypes)
Range 0x250000 - 0x25ffff: reserved for 'model/*' (there currently are ~24 subtypes)
Range 0x260000 - 0x26ffff: reserved for 'multipart/*' (there currently are ~13 subtypes)
Range 0x270000 - 0x27ffff: reserved for 'text/*' (there currently are ~71 subtypes)
Range 0x280000 - 0x28ffff: reserved for 'video/*' (there currently are ~78 subtypes)

That's 0.18% of the 4 byte range and it gives us an even 16 bits (65536) entries for each subtype. We could even give "application" a larger range to make room for new types.

---

IIRC, there's already a numeric registry for MIME types somewhere. Are you aware of one? If that's the case, it would be great if we could map that into a range of multicodecs.

[Stebalien]

Replaced by #159.