Update of Doohickey/AddTrack proposal

Based on some feedback I've received, I've slightly updated my proposal
(originally inspired by Martin) on doohickeys and replacing AddStream with
AddTrack. See below:

------------------------------------------------------------------------

I suggest we call the SendDoohickeys RtpSenders and the corresponding
receive-side objects RtpReceivers. These objects allow control of how a
MediaStreamTrack is encoded and sent on the wire, including "hold" state,
prioritization, and multiple encodings (e.g. simulcast).

You get a RtpSender as a return value from AddTrack (which replaces
AddStream). You get a RtpReceiver as an argument to the new onaddtrack
callback (which replaces onaddstream). The actual track object can be
obtained as a property from the RtpReceiver (see below).

For getting access to ICE/DTLS info, both RtpSenders and RtpReceivers can
also have a reference to a DtlsTransport object, which will have its own
state variables, including the RTCIceConnectionState of that particular
transport, and the .remoteCertificates for the DTLS connection. This allows
applications to monitor the state of individual transports, as well as
inspect the certificates for individual transports.

The actual interface is as follows:

interface DtlsTransport {
  attribute RTCIceConnectionState state;
  attribute sequence<ArrayBuffer> remoteCertificates;
  //... more stuff as needed
};

interface RtpSender {
  readonly attribute MediaStreamTrack track;
  readonly attribute DtlsTransport transport;
  // various tweakable attributes
  attribute bool active;  // controls "am I sending RTP"
  attribute PriorityLevel priority;  // for relative bandwidth allocation
  // for multiple encodings: simulcast (audio or video), layered coding
  // specify the codec to use, resolution, bitrate, and any dependencies
for each encoding
  attribute sequence<EncodingParams> encodings;
};

interface RtpReceiver {
  readonly attribute Transport transport;
  readonly attribute MediaStreamTrack track;
  // more stuff as needed
};

partial interface PeerConnection {
  RtpSender addTrack(MST);  // replaces addStream
  void removeTrack(RtpSender);  // replaces removeStream
  readonly attribute sequence<RtpSender> senders;
  readonly attribute sequence<RtpReceiver> receivers;
  EventHandler onaddtrack;  // replaces onaddstream; onremovestream is not
needed
};

For backcompat, addStream, removeStream, getLocalStreams, getRemoteStreams,
and onaddstream can be trivially polyfilled in JS, so there is minimal
impact on current applications.

All together, the pipeline looks like this:

Source ---> MST ---> RtpSender ---> Transport ---> (The Internet) --->
Transport ---> RtpReceiver ---> MST ---> <video/>

Each RtpSender/Receiver references a single MST, although a single
RtpSender/Receiver can send/receive multiple encodings (e.g. simulcast).
There are N RtpSenders/Receivers per Transport; N is controlled by the
policy specified for BUNDLE.