Next steps on RTCRtpSender "doohickey" proposal

Trying to bring this discussion to a conclusion... I sense consensus around
the following:
- General concept of doohickeys, i.e. RTCRtpSender, RTPRtpReceiver.
- addTrack(track, streamId)/removeTrack and onaddtrack.
- Implicit cloning never occurs. This means that if you want to add a track
twice to a PC, you need to first clone it.

More discussion is still needed on:
- RTCRtpEncodingParams
- RTCDtlsTransport

Therefore I would like to advance the initial, uncontroversial parts of
this proposal, i.e. what I describe below. We can then discuss the exact
nature of the encodings and transport objects separately on the list, and
at the interim meeting.

// the "send" doohickey

interface RTCRtpSender {

 readonly attribute MediaStreamTrack track;

};

// the "receive" doohickey

interface RTCRtpReceiver {

 readonly attribute MediaStreamTrack track;

};

// parameter to the onaddtrack event

interface AddTrackEvent : Event {

 readonly attribute RtpReceiver receiver;

 readonly attribute MediaStreamTrack track;

 readonly attribute MediaStream stream;

};

partial interface RTCPeerConnection {

// because a track can be part of multiple streams, the id parameter

  // indicates which particular stream should be referenced in signaling

 RTCRtpSender addTrack(track, streamId);  // replaces addStream; fails if
|track| has already been added

 void removeTrack(RTCRtpSender);  // replaces removeStream

 sequence<RTCRtpSender> getSenders();

 sequence<RTCRtpReceiver> getReceivers();

 EventHandler onaddtrack;  // replaces onaddstream; event object is
RemoteTrackEvent.

                                        // note that onremovestream is not
needed, since tracks are 'removed'

                                        // simply by progressing to the
ENDED state

};