A little cleanup
multiShot + multiShotEvents for HTML5 Audio()-based sounds, allowing layered / "chorused" playback if play() is called and multiShot: true has been specified to either createSound() or play(). Behaviour should mimic that of Flash 9. If multiShotEvents: true is specified, onfinish() will fire for each instance.

Implementation summary: A new Audio(src) instance is created, with an onfinish listener, and played immediately. It is unloaded and destroyed when playback finishes.

Caveat #1: If a position argument is provided eg., play({ position: 1000 }), the cloned Audio() instance must wait for a HTML5 "canplay" event before a seek and playback can begin. This may mean playback *could* have a slight delay vs. playing without the position offset.

Caveat #2: The from/to parameters used for "sound sprites", e.g., { from: 500, to: 1500 }, are not presently supported under multiShot.

Caveat #3: multiShot is not supported where only a single audio instance can be playing at once, e.g., iOS (iPhone/iPad) and some Android devices.

Secondary instances are "fire-and-forget", similar to the Flash 9 implementation, and fire no events other than onfinish(). They do not respond to position, volume etc. after playback has begun.

HTML5 unloading: Firefox was supposed to like assigning '' to Audio().url for canceling requests, unloading and destroying the decoder (perhaps only on <audio>, in retrospect?) - similarly, .src = null did not seem to work, possible request to ./ - undesirable.
Now using more-conservative Audio().url = (isSafari && !is_iDevice ? null : (isFirefox ? emptyURL : null)); where emptyURL is user-customizable, 'about:blank' by default.