"Factory-style" AudioWorker spec proposal

Hi group,

It was great seeing so many of you in person in Paris.

In the spirit of keeping the discussion moving on AudioWorker, I've posted
a version of the spec that embodies the idea of AudioWorker acting as a
factory for AudioWorkerNodes.  This allows AudioWorkerNodes to be created
synchronously (or, at least, as synchronously as native nodes), because the
script loading phase only occurs once up front, when an AudioWorker is
created.  The nodes for that worker are created later, after the
AudioWorker is up and running and its script has run.  The
AudioWorkerGlobalScope now has an onaudionodecreated handler, called each
time the factory makes a new node.  That in turn takes care of attaching an
onaudioprocess handler to the newly created node, as well as doing whatever
other setup is needed for the node.

You can see my proposal here:

   http://joeberkovitz.github.io/web-audio-api/

I suggest jumping straight to the reworked bitcrusher / VU-meter sample
code snippets to get the idea and then reading the revised/added interface
definitions.

Overall it's not far from Jussi's proposal from Sept. 2014 in terms of
overall concept and naming. There are some differences though.  Also, it's
forked from Chris Wilson's last published revision and incorporates Chris's
work on the configurable-input-output changes. Diffs in my version can be
viewed here:


https://github.com/joeberkovitz/web-audio-api/commit/0581c5bddfdacf1e9bef075f91dc76c18e186bda

A few other highlights for possible discussion:

1. I moved the configuration of node parameters and inputs/outputs into the
worker script. The argument that these things must be configured in the
main thread prior to node creation no longer applies (since the entire
AudioWorker script now runs prior to node creation). From a packaging point
of view it seemed much nicer to have these shared characteristics of nodes
defined in the script, not the main thread -- Norbert Schnell raised this
issue at the WAC conference.  However, this does imply that a single
AudioWorker can't leverage its script to somehow create nodes with
different AudioParams or input or output configurations. Others might feel
differently about this tradeoff.

2. I allowed the node-creation method on AudioWorker to pass some initial
Transferable data for the new node, because it felt analogous to the
constructor args taken by most native nodes.  Maybe this amounts to sugar
in place of explicitly calling postMessage() on the node immediately after
its creation, as in Chris's VU meter example. So perhaps this extra
data-passing opportunity should be taken out -- but I thought the creation
event for a node was special enough to merit some data being passed in to
initialize it.

Anyway, hope this is helpful. I'm sure it needs lots more critiquing and
work.

...Joe