Clear document describing some serialization formats.

Notes:

Section 3.1:

* The "ind" field is defined as a 32-bit bitfield of types.  This constraint on the range of expressible message types seems hard to justify.  In the common case, a short list of small integers would be almost as compact (in CBOR), and in the extreme case (32 message types), the proportional savings of using a bitfield is presumably minimal compared to the messages themselves.  This seems like a case of trying to save 1 byte, at the cost of considerably reduced flexibility for extensions (especially experimental or private extensions).  And in some cases, the bitfield representation is actually _less_ compact.
* Also, the description says "Only four values are registered", but the definition of `cm-type` shows 5 values.

Section 3.4:

* It seems like this text is recommending sending JSON or CBOR in a shared container, with the recipient disambiguating them based on the first byte.
  - It's not clear what the motivating use case is for this algorithm.
  - This is a risky design.  Parsers developed in JSON-only or CBOR-only ecosystems may sensibly omit the unused format, leading to misbehaviors when they are used with other format.
  - The proposed disambiguation is different from the one proposed in the CBOR specification (see https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.6-4, https://www.rfc-editor.org/rfc/rfc9277.html#section-2.2)
  - Unless there is a compelling reason, it would seem safer to treat JSON and CBOR consistently as distinct media types, distinguished by an indicator in the upper layer (as is done in Section 4.4 for X.509).

Section 10.5
* The IANA registry is given as "expert review", but the instructions to the expert effectively make the policy equivalent to Standards Action (or perhaps even stricter!).  IMHO it should be changed to Standards Action.  (A non-bitfield representation would allow a much more relaxed registration policy.)