[codec] Multi-mode frame concatenation

["Benjamin M. Schwartz" <[e-mail]>]

Given the hum in favor of frame concatenation within the codec, I would
like to propose the following addition for multi-mode concatenation in
Code 3 (circa page 14):

"""
If M == 49, p == 0, and v == 1, then the packet is a "multi-mode packet".
 The decoder MUST read the next byte to determine the true values of M, p,
and v.  Decode shall then continue as normal, except that each frame shall
be interpreted as a Code 0 packet.  Decoders MUST NOT continue decoding
the packet if any frame indicates a code other than 0.
"""

This design has zero overhead when not used, and should be as simple as
possible to implement and test.  The implementation lives entirely inside
the codec, so its complexity is no more a problem for the user than is the
complexity of the CELT collapse-prevention system.  The described mode is
currently invalid, so it does not represent a significant change; all
previously valid bitstreams are unaffected.

This design improves security by ensuring that a gateway can always
convert any Opus stream into a CBR stream at a constant packet rate.
Currently, this is not true due to mode switching boundaries, resulting in
information leakage (e.g. whether someone is talking or still listening to
the hold music.)

This design improves interoperability by ensuring that anyone who requires
such functionality is not tempted to implement it in their own layer.

This design improves bitrate efficiency when using Code 1-3 by avoiding an
additional packet's overhead (e.g. RTP+UDP+IP) on every mode switch.

This design allows encoders to switch modes freely, with limited and
predictable overhead.  In the present system, each mode switch is
associated with the unpredictable and potentially large cost of forcing a
packet boundary.  Making this cost more predictable allows an encoder to
switch modes more frequently (i.e. employ RDO) in order to improve
compression, for example by varying the bandpass or framesize based on
signal content.

This design is particularly beneficial in certain advanced applications
such as a multichannel extension where a group of packets must all start
and stop on a shared time boundary.  Without this design, all mode changes
in all channels must occur on that boundary as well.