Improve WebAudio messaging model to match Firefox

[Manishearth]

The way it's currently set up, WebAudio JS API calls may end up occurring on different render quanta even if they occur in the same task. Plus, currentTime is a cross-thread sync call which is no good.

I discussed this with @padenot and the Firefox model seems like a good way to go forward here.

What Firefox does is:

• Batches up all messages to the render thread till steady state
• currentTime is kept up to date on the main/DOM thread via an event sent to the main thread every render quantum
• Node creation messages are not batched, and instead are executed immediately (waiting for the NodeId to be returned).
• To be able to throw errors we must maintain AudioParam timelines on both sides. Oh well. We don't need to do this for the entire graph, fortunately.

Worth noting: Chrome handles currentTime with an atomic (so it may update underneath you), but we can't do that anyway because of a possible process boundary.

cc @ferjm

[Manishearth]

I think for the reverse -- the render thread messaging the DOM -- we should also use a single pipeline. This goes for:

• currentTime updates
• offlineaudiocontext completion events
• AnalyserNode update events

This doesn't affect synchronous DOM calls that need to wait on WebAudio.

[Manishearth]

The AudioParam fixes will also be needed to implement param-dependent things like BiquadFilterNode::getFrequencyResponse().

Note that currently AudioParams don't like being only occasionally updated -- if they end up skipping events entirely the start values can be wrong. This will also need to be fixed.

[Manishearth]

There also may be timing issues when you start audiocontexts.