RtpParameters encodings: leave the door open for many, or There Can Only Be One?

Recently, I wrote up a PR reflecting what I thought we (roughly) agreed up
on at TPAC 2014: https://github.com/w3c/webrtc-pc/pull/234.

In it, I basically added this:

dictionary RtpParameters {
  sequence<RtpEncodingParameters> encodings;
}

dictionary RtpEncodingParameters {
  bool active;
  float priority;
}


You'll notice that this leaves open the door for multiple encodings per
RtpSender, for example for simulcast.  The idea at TPAC, if I recall
correctly, was to allow for multiple encodings in the structure of the
parameters, but to only allow one encoding in WebRTC 1.0 (simulcast could
be addressed in future versions, but the structure would be there).

However, there was less discussion and consensus around multiple encodings
than there was of the parameters model in general, and recently on the list
there has been doubt whether we should put it in there.

The alternative (call it B) would be to do flatten the structure like so:

dictionary RtpParameters {
  bool active;
  float priority;
}

// No RtpEncodingParameters dictionary


And then later when we decide that we do need multiple encodings, try and
add it in a backwards-compatible way.  One way suggested to me would be do
add it like this later:

dictionary RtpParameters {
  // These values are shared between all encodings, unless overidden by
".encodings".
  bool active;
  float priority;
  sequence<RtpEncodingParameters> encodings;
}

dictionary RtpEncodingParameters {
  // These values override the values shared by all encodings
  bool active;
  float priority;
}

So, which shall it be?  Put in room now for expansion later, or simplify a
bit and figure out expansion later?