Suggestion for changes to IceGatherer to make it possible to signal IceParameters without gathering

While Philipp Hancke has been working on the "shim" of writing
PeerConnection in Javascript on top of ORTC, he discovered that it's
difficult to generate and signal (or, in his case, create an SDP offer) the
IceParameters (ufrag and pwd) without actually starting the process of
gathering candidates.  As soon as the JS creates an IceGatherer to get the
local IceParameters, candidates are gathered, which is annoying, because
one would like to gather those later.  In fact, at that point in a call
flow, it would be nice to not even have to construct an IceGatherer at all.

We have a similar situation with DtlsTransport, where one would like to
generate a certificate before constructing the DtlsTransport, and then pass
that certificate into the DtlsTransport constructor.  So I propose we add
the following to IceGatherer to allow for the same construct:

[Constructor(IceParameters localParameters, RTCIceGatherOptions options)]
partial interface IceGatherer {
  static IceParameters generateLocalParameters();
}

That way, one could do this:

var iceParams = IceGatherer.generateLocalParameters();
// ... signal them or generate an SDP offer
var iceGatherer = new IceGatherer(iceParams, ...)



Also, although we thought we wouldn't need a "start" method, I think we've
no learned that having one would be valuable.

partial interface IceGatherer {
  void start();
}


The semantics can be very simple:
- A constructed IceGatherer is in the "new" state until the gatherer is
started.
- An IceGatherer can only be started once.
- If an IceGatherer is passed into an IceTransport and the IceTransport is
started, the IceGatherer is also started.


I think these two things would resolve all the issues that Philipp Hancke
found while writing the shim and also provide more flexibility to all
applications with very little additional complexity in the specification or
implementation.