First cut at fixing the whole "queue a task" mess

This turned out to be a little tricky.  Rather than redefine "queue a task", which would have touched a lot of the spec (see the first commit here, which is basically content-free), I've defined a new label.  "Queue an RTCPeerConnection task" is a new definition that this adds, which is attached to a PC-specific task queue.  This serializes all of the mutation functions: create{Offer|Answer}, set{Local|Remote}Description, {add|remove}Track, createDataChannel and getIdentityAssertion.

This probably needs careful review.
IMHO the operations-serializing chain in http://w3c.github.io/webrtc-pc/#operation (down a bit) is not a "task queue" at all. A task queue is a list of synchronous events in an event-loop, whereas the RTCPeerConnection thing is effectively a promise-chain of asynchronous operations that block on not just the launching of the previous operation but the completion of it. That's different.

I propose we alter the language more substantially to separate these two concepts. In fact, we've just successfully replaced our implementation of the operations array with a promise-chain (http://bugzil.la/1106675 ) so perhaps the spec language can benefit from a similar update?

I apologize, when I initially read this PR I missed big parts and thought we were merely modifying "queue a task" to "queue a task that checks we're not closed", which I think we also need for a lot of our success callbacks.