Changes

rtp2trau_hr16: set D bits correctly

The original code failed to do the step of osmo_pbit2ubit() for
transferring HRv1 payload bits from packed to unpacked form,
instead doing the bogon of memcpy()ing the RTP payload directly
into tf->d_bits array - fix it.  Also set all D bits to zeros
in the case of empty payload input - not ideal, but better than
transmitting uninitialized memory content.

Change-Id: Icb6a21a12fe82f6637f327d45bd843686a90a458

rtp2trau_hr16: accept both TS 101 318 and RFC 5993 payload formats

OsmoBTS already accepts both payload formats for HRv1 - do likewise
when interfacing to E1-based BTS.  While OsmoMGW does have a vty
config option to convert between TS 101 318 and RFC 5993 payload
formats on the fly, it should be considered deprecated, and we
should be moving toward recommended configurations with that option
disabled.

Change-Id: I125d57d3451b030e35a7b2b95a45e38b4581626c

trau2rtp_hr16: change output format to RFC 5993

Emitting RFC 5993 payload format instead of TS 101 318 brings
Osmocom+E1 BSS into compliance with TS 48.103 (which requires
RFC 5993 format at AoIP interface), and will also make it much
easier to add optional support for TW-TS-002.

There are no backward compatibility issues: OsmoMGW E1 support
currently works only for FR and EFR, not for HR.

Related: OS#6448
Change-Id: I0bcfdccbf4df5a5cd90a65525527f08107be2cf5

RTP->TRAU, FR/EFR: accept TW-TS-001 extended payloads

TW-TS-001 is an enhanced RTP transport format for FR and EFR
codecs that replicates the functionality and semantics of
GSM 08.60 TRAU-UL frames.  Given that libosmotrau functions
support converting from RTP to either TRAU-UL or TRAU-DL,
the option of TW-TS-001 fits in naturally.

It needs to be noted, however, that the fully correct path
in OsmoMGW from RTP input to E1 output will need to include
one more critical step _before_ the call to osmo_rtp2trau():
it will be a stateful preening engine that implements the rules
of TS 28.062 section C.3.2.1.1, a codec-dependent stateful
transform that can be fairly complex.  The necessary engines
will most likely be implemented in Themyscira codec libraries,
and OsmoMGW will need to be outfitted with an _optional_
dependency on those libs.  The "native" support for TW-TS-001
input in osmo_rtp2trau() for TRAU-DL (as opposed to TRAU-UL)
output is a fallback in the case of OsmoMGW built without any
Themyscira codec libraries.

Related: OS#6448
Change-Id: I3b2a33c1fcc5a7dafe06736dce5fa5b7b1138e54