Redundant queuing in gathering state computation risks eliding events

[jan-ivar]

Similar to #2020 but for gathering states (we fixed this for connection states, but not gathering states).

Quoting the spec:

When the ICE Agent indicates that it began gathering a generation of candidates for an RTCIceTransport, the user agent MUST queue a task that runs the following steps: [...]

4. Set transport.[[IceGathererState]] to gathering.

5. Fire an event named gatheringstatechange at transport.

6. Update the ICE gathering state of connection.

Since Update the ICE gathering state ALSO queues a task, we're queuing a task from inside another, to, among other things:

2. Let newState be the value of deriving a new state value as described by the RTCIceGatheringState enum.

@docfaraday noticed this puts us at risk of eliding icegatheringstatechange events, since the state derived by the time the second queued task runs may be different.

The solution seems to be to fire both gatheringstatechange (on transport) and icegatheringstatechange (on connection) from the same task, like we did with the connection states in #2400 and #2444 to solve similar concerns.

Web compat

WPT coverage here is poor, but this fiddle shows only Safari is firing "gathering" on the ice transport at all (see sender.transport.iceTransport.ongatheringstatechange), so there should be time to align timing and ordering here with the rest of the spec.