Changes

osmo_trau_frame_encode(): fix encoding of 16k O&M frames

The behavior of osmo_trau_frame_encode() for OSMO_TRAU16_FT_OAM
has the same unfortunate (but now officially documented) design
quirk as all other 16k frame types: bits C1..C5 are set internally
by the encoding function and not from caller-supplied fr->c_bits[].
However, there was also a bug: bits C6..C15, which are taken from
fr->c_bits[] for all frame types, were copied from the wrong part
of this fr->c_bits[] array.  Fix the latter bug.

Change-Id: Ia366d5b0385b764c492bbed9a030ca27db71fcff

osmo_trau_frame_encode(): reduce space requirement in common case

Since its introduction in 2020, osmo_trau_frame_encode() API has had
the ability to emit TRAU-DL frames that are either lengthened or
shortened for timing adjustment, like real TRAUs do.  However, this
capability was never exercised in OsmoMGW-E1, nor is it used in the
new tw-e1abis-mgw: given the constraint of having to submit 160-byte
blocks to the E1 stack every 20 ms, it is not really feasible for
our current sw-only implementation to achieve the same 125 us timing
optimizations that are possible and desirable in a hardware or FPGA
implementation.

Since all current users of osmo_trau_frame_encode() API call it with
fr->dl_ta_usec set to 0, the doubled output space requirement imposed
by the function becomes an unnecessary burden and an API design bug
in need of fixing.  Solution: check fr->dir and fr->dl_ta_usec to see
if frame output lengthening is actually possible for each given
invocation of this function, and require doubled output space only
in those cases.

Change-Id: I9f3541b0618ebef26e53b69041e5b74abefd3b85

trau_frame: add support for config frames of 3GPP Rel5+

3GPP Rel5 introduced Generic Config Frame format for TFO, defined
in TS 28.062 Annex H (globally interoperable interface), and also
defined equivalent Speech Codec Configuration Exchange frames on
Abis (treated mostly as vendor-private interface by this point),
added to TS 48.060 and 48.061.  These Generic Config Frames are
mandatory for AMR-WB codec, which not only requires TFO in order
to be useful (in the absence of all-IP TrFO), but also lacks the
ability to stuff TFO config parameters into regular speech frames
in the way that was specified in 3GPP Rel4 for AMR-NB.

Support for these GCFs on Abis is necessary in order to support
TFO-AMR with some vendors' E1 BTS.  Some vendors of TDM-based
GSM BSS felt no interest in TFO-AMR for its own sake, and only
implemented TFO support for AMR (both NB and WB) when forced
to do so by AMR-WB market demand; these vendors (Nokia is one known
case) skipped 3GPP Rel4 version of TFO-AMR and went directly for
Rel5 version, using Generic Config Frames on Abis for both AMR-NB
and AMR-WB.

Change-Id: Ifbde07e4a3fb80e4faa0b6a6b32938ed98371c5b