A proposal for returning STUN/TURN server errors to applications

Currently, there is no way to know if you failed to get STUN/TURN
candidates from the servers specified in RTCConfiguration, except by
working backwards from the generated candidates to see if they match what
you expect, which is inexact at best.

This includes cases where the server is unreachable (due to server problems
or a bad URI), as well as authentication failures.

To improve this situation, I suggest the following changes:
- in RTCPeerConnectionIceEvent, add the URI for the RTCIceServer used to
generate the candidate as a new |uri| parameter. For host candidates, this
parameter will be null. This will allow apps to know if they were able to
successfully obtain candidates from a specific STUN/TURN server.
- add a new onicecandidateerror event, which emits an event for every URI
that did not generate the expected candidates (e.g. srflx for a STUN
server, relay for a TURN server). The onicecandidateerror event has two
fields, |uri|, and |code|, where code is either the error from the server,
or some 6xx error code if the connection failed.

In some cases, it could be possible to get both a success and error event
from the same server, e.g. if a STUN address was allocated but a TURN
request failed.