Proposal for a way to set the send codec on an RtpSender.

When I meet up with application developers one of the first things they
want to know is how to change codecs.   And the response "well, you can
munge SDP" never goes over very well.

So, I've been thinking about a way we can allow developers/apps to control
the codecs without munging SDP, but also without adding a lot of complexity
to the API.  And now that we have RtpSenders and RtpSender.setParameters
(at least in this PR: https://github.com/w3c/webrtc-pc/pull/234), I think
there is a way.

I propose we allow apps to do this:

var params = sender.getParameters();
var myFavoritePayloadType;
for (var i = 0; i < params.codecs.length(); i++) {
  if (params.codecs[i].name == "myFavoriteCodec") {
    myFavoriatePayloadType = params.codecs[i].payloadType;
  }
}
if (myFavoritePayloadType) {
  params.encodings[0].payloadType = myFavoritePayloadType;
  sender.setParameters(params);
}



In other words, an app can:
1.  Get all the codecs currently available.
2.  Find the one it wants to send with (by name or other attributes).
3.  If it's available, choose it (by an ID, and the ID we use is
payloadType).


And we can accomplish that by adding the following to RTCRtpParameters:

partial dictionary RTCRtpParameters {
  sequence<RTCRtpCodecParameters> codecs;
}

dictionary RTCRtpCodecParameters {
  unsigned short payloadType;
  DOMString name;
  unsigned short channels;  // mono=1, stereo=2
}

partial dictionary RTCRtpEncodingParameters {
  unsigned short payloadType;
}

An alternative would be to allow the app to alter RTCRtpParameters.codecs,
such as by reordering them.  But I think allowing the app to alter
RTCRtpParameters.codecs opens up too much complication, because potentially
that would change the SDP.

And, naturally, we could add more things to RTCRtpCodecParameters: such as
clockrate and codec parameters.   But we should probably stick with the
ones that an app would actually want to use for selecting among several
codecs.


In summary, I think this is a reasonably low-complexity way of adding
something that's very valuable to applications and developers and builds on
top of the work we've already done with RtpSender.