Should we add a RIDs parameter to PeerConnection.addTrack?

In a previous thread, we discussed how RIDs should be read-only, but that
brought up the question: could we allow RIDs to be passed into addTrack?

Initially, I thought we shouldn't allow that because then if the RtpSender
returned were bound to an existing m-line with a remote description, then
the RIDs could conflict.  However, after thinking about it more I realized
that it would be possible if we made this rule:  if RIDs are specified in
addTrack, then addTrack must create a new RtpSender, not use an existing
one, just like addTransceiver does.  Then, it would use the same rules as
addTransceiver and be safe from this problem.

The only problem I can think is that an app developer might be surprised
when a transceiver is reused in some cases, but then not when RIDs are
specified.  But that seems like a pretty small issue.

If we do choose to add RIDs to addTrack with this rule, I think we should
expand addTrack to take a full "sequence<RTCRtpEncodingParameters>
sendEncodings", just like addTransceivers, with the same rules, so that
they are consistent with each other.  We may even consider packaging it
into an RtpSenderInit dictionary similar to RtpTransceiverInit.  That would
be a cleaner place to put .streams anyway.

Something like:

dictionary RTCRtpSenderInit {
  sequence<MediaStream> streams;
  sequence<RTCRtpEncodingParameters> sendEncodings;
};

partial interface PeerConnection {
  RTCRtpSender addTrack (MediaStreamTrack track, RTCRtpSenderInit init);
}