Mark functions incompatible with SharedArrayBuffer and provide alternative signatures

[kettle11]

Presently browser's will crash if copyToChannel(source, channelNumber) is called with a Float32Array that is backed by a SharedArrayBuffer. I opened an issue on that here: WebAudio/web-audio-api#2565

While the browser's copyToChannel function accepts a Float32Array as the source argument web-sys instead takes in a &[f32]. This is likely for convenience but it also makes it impossible to use web_sys's copy_to_channel in cases where the Float32Array was acquired from a source that's not the Wasm instance's memory. This seems like an API oversight to me.

This limitation means that if the memory is backed by a SharedArrayBuffer copy_to_channel simply cannot be used without causing a crash.

That makes workarounds, like the one required for this issue: RustAudio/cpal#656, a little messier.

Workarounds are possible but it also seems like the web_sys API should consider changing.

[daxpedda]

Agreed, probably all methods which take a view should probably also generate a function which takes an appropriate array buffer. I think it would be nice to figure out a way to pass both at the same time (e.g. with a trait), but that would be a breaking change.
Additionally, to fix the current behavior, it might be good to guard this method behind a cfg(not(target_feature = "atomics")).

Happy to review a PR!