Remove audio-params component

[johnshaughnessy]

This PR removes the audio-params aframe component and introduces a simple contract for handling audio nodes and audio settings.

The contract is:

• When a THREE.Audio is created, we put it in APP.audios and we call updateAudioSettings.
• We put any state that affects audio settings into various collections (APP.sceneOverrides, APP.zoneOverrides, etc). When state is added or removed from these collections, we call updateAudioSettings.

The updateAudioSettings function reduces over the collections to determine what the audio settings should be and then applies them. When reviewing this PR, I recommend that you start by reading updateAudioSettings: https://github.com/mozilla/hubs/blob/audio-refactor-v1/src/update-audio-settings.js

This fixes a few problems:

• In the previous code, whichever "layer" of audio settings were set most recently overwrites all previous state. For example, the user might enter an audio zone which affects the gain of an audio node. Then, the user might dismiss a linked copy of that node (via linked-media) and reset the gain to 0.5. The effect from the zone is overwritten (which is not desired). This type of problem is repeated at every "layer".
• In the previous code, we kept duplicate copies of panner node data in the audio-params component. This meant we had a bunch of book-keeping code to keep data in sync. There were subtle bugs in that book-keeping code that meant the two diverged. This is fixed by getting rid of the indirection and second copies of the "same" data.
• In the previous code, we had bugs related to the initialization order of aframe components. One component looked for properties of another component that may not have been initialized yet. (For example, Cannot read property 'data' of undefinedCannot read property 'data' of undefined #4456 ). In this PR, whenever we have a new setting for audio, we can confidently store it in our collections (whether the audio for the element in question exists yet or not). If there exists an audio, we update its settings. If not, we know that our settings were stored in the collection and will be used once the audio is created.
• Similarly, in the previous code, any settings that affects an element's audio node would be lost if we replace that element's audio node with a new one (as in the case of switching from a PositionalAudio to a regular Audio). Although the code paths that handle this kind of replacement need further investigation, it is easy to tell what should happen in these cases: The node should be replaced and the associated settings should be applied to the new node.

The AudioNormalization code is no longer being used and should be re-introduced in a followup PR.

┆Issue is synchronized with this Jira Task