Investigate simplifying the code to resume the audio context

[jbphet]

The way in which the audio context is supposed to be resumed has gone through a lot of churn lately for the various browser vendors, but I think the policy that Chrome has decided upon may allow us to simplify the code as it currently exists. The piece of information that I came across was an explanation of Chrome's autoplay policy at https://developers.google.com/web/updates/2018/11/web-audio-autoplay. The salient bit was this:

An AudioContext will be resumed automatically when two conditions are met:

• The user has interacted with a page.
• The start() method of a source node is called.

The way SoundClip and other objects that use audio source buffers handles a non-running audio context is to buffer the request and wait until the audio context starts running, then play it. This may now be unnecessary.

To test this, I should probably build a version of tambo off of a branch, than check it on a number of platforms, then have QA do the same thing. I'm also wondering if this might have an impact on the quality of the first sound produced by the sim, making it have a "soft attack", since I've heard this in other cases.

For reference, #9 is a closely related issue.

[jbphet]

@emily-phet suggests having this on the list of code improvements for the quarter that starts in July 2019, and holding off on it until then. Marking as deferred until then.

[jbphet]

While creating MultiClip, I ran into a situation where I needed to pass a parameter to the play function that was used to do a deferred play operation while waiting for the audio context to change state in response to a user action. Since this would have added complexity, I decided to try and remove the deferred playback altogether and see if things still worked, since the information above would seem to imply that it now should. It appears to work on the most recent versions of Chrome and Firefox. When I get back to this issue, I can use this code as a starting point to test how this approach behaves on all browsers.

For reference, MultiClip was integrated into the tambo demo to play the screen selection sounds so, if this hasn't changed by the time I get back to this issue, screen selection sound generation can be a test case for all browsers.