wasm-bindgen: Gecko's WebIDL can be wrong for other browsers

We originally lifted our WebIDL definitions from Gecko, which means we’re highly likely to work in Firefox which uses that exact WebIDL (yay!). Over time though we’re discovering that Gecko’s WebIDL isn’t what’s used by other browsers.

Examples discovered so far:

• AudioScheduledStartNode exists in our WebIDL, but in webkit the methods are defined inherently in classes which inherit from AudioScheduledStartNode (like OscillatorNode)
• BaseAudioContext doesn’t exist in Safari, looking like it’s also inlined on AudioContext.

These definition issues aren’t generally a problem for the web platform but they’re a problem for us in that we’re plucking our raw function pointers for maximal performance, and those raw function pointers are located in different places.

Ok with that in mind, how do we want to solve this? I don’t think we want to include WebIDL from all browsers and take the union, but rather what I think we can do is to basically just massage our WebIDL to become more browser-agnostic over time. Put another way, we should do this:

• For AudioScheduledStartNode, switch it to a mixin.
• All classes which inherit from AudioScheduledStartNode now have Foo includes AudioScheduledStartNode and inherit from AudioScheduledStartNode’s original parent

Transformations like that mean that we’re modeling the web platform slightly differently, but it should effectively have the same result. The wasm-bindgen generated bindings already look up the inheritance chain for the right function pointer, which means that we’ll still use all the native methods on BaseAudioContext in Firefox and we’ll otherwise use the methods on AudioContext in Safari.

The downside of this approach is that it’s a breaking change for web-sys, although I think we may be able to get around that by, for example, moving all the methods in interface AudioScheduledStartNode into a interface mixin rustAudioScheduledStartNode and then include that in various interfaces. That… shouldn’t be a breaking change I think in general but it doesn’t fix methods which take AudioScheduledStartNode as a parameter, for example (as that type just doesn’t exist in WebIDL).

In any case, do others have thoughts on this? Other ideas on how we’ll cope with these differences?