There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk.  It uses only one mapping structure to
associate payload types to codecs.  The single mapping is overkill if all
of the payload type values are well known values.  Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive.  Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.

1) An independent payload type mapping is needed for sending and
receiving.

2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.

3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.

* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.

* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.

* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created.  All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.

* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP.  We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac