Write PeerConnection's operations array as a chain

The spec's "operations array" [1] is under-specified and unconventional 
by today's standards. Here it is:
>
> ..., for every call to |createOffer|, |setLocalDescription|, 
> |createAnswer| and |setRemoteDescription|; execute the following steps:
>
> 1.
>
>     Append an object representing the current call being handled (i.e.
>     function name and corresponding arguments) to the |operations| array.
>
> 2.
>
>     If the length of the |operations| array is exactly 1, execute the
>     function from the front of the queue asynchronously.
>
> 3.
>
>     When the asynchronous operation completes (either successfully or
>     with an error), remove the corresponding object from the
>     |operations| array. After removal, if the array is non-empty,
>     execute the first object queued asynchronously and repeat this
>     step on completion.
>
> The general idea is to have only one among |createOffer|, 
> |setLocalDescription|, |createAnswer| and |setRemoteDescription| 
> executing at any given time. If subsequent calls are made while one of 
> them is still executing, they are added to a queue and processed when 
> the previous operation is fully completed.
>

TL;DR... This is a modest hand-rolled promise chain, defined before 
promises were common. I propose we modernize the language to take 
advantage of this well-defined behavior that is available.

See PR [2] for language. Firefox release currently implements this PR 
(see code [3]).

> It is valid, and expected, for normal error handling procedures to be 
> applied.
>

What "normal error handling procedures"? For that matter, what is an 
"asynchronous operation"? The PR adds standard language to isolate 
errors from propagating the chain.

.: Jan-Ivar :.

[1] http://w3c.github.io/webrtc-pc/#operation
[2] https://github.com/w3c/webrtc-pc/pull/165
[3] 
http://mxr.mozilla.org/mozilla-central/source/dom/media/PeerConnection.js?rev=b11576671375#383