adding BaseAudioContext

[chrisdavidmills]

Yes, I know it's a mixin, but I decided to just get it done anyway, as we can always edit it later.

One point of contention — a lot of these features used to hang off AudioContext, but were later moved to BaseAudioContext. I've dealt with this by adding notes to the data points in question, but I wasn't sure if

a. This was the best way to deal with it, or
b. If anything else was needed. For example, It might possibly be helpful to state somewhere exactly what versions of browsers first supported them on AudioContext, and when the prefixes were dropped. BUT this would be a nightmare to represent, so thus far I haven't tried ;-)

[Elchi3]

I'm unsure about this one. The discussion in #472 is not yet resolved.

Compat information, as well as MDN web docs, should be practical for web developers, but is it really useful information if something was "Previously available on the AudioContext interface."? As a web dev, do I need to change my code now?

My understanding is that it is more of an aspect of how things are specified by the Web Audio specification. How it's exposed, meaning how web developers can use it in the end, has not changed at all, right? The spec authors move around a lot interfaces and mixins to define APIs, but that rarely means the way things are exposed change. So, why would we follow the spec language changes and not just stick to what is exposed? I haven't looked at all this very deep, but I think I need an example that convinces me that the spec language changes are actually relevant to web developers.

It's likely a larger conversation we not only need to have for BCD but also for MDN. At least that's what I get from the thoughts in #472.

[Elchi3]

This needs a rebase now and discussions aren't really resolved on mixins yet. I'm closing this for now. Will come back to this and can re-open at some point.