BYOB support for controlTransferIn, transferIn and isochronousTransferIn

[reillyeon]

Profiling done by a developer reporting a Chromium issue shows that allocating lots of small buffers for transfer results creates significant GC pressure when transfering data at high speed. We should consider supporting a "bring your own buffer" mode similar to what is done in the WHATWG Streams API.

We will need to measure whether this results in a practical improvement given that transfer results must also allocate an IDL dictionary for the result metadata.

[reillyeon]

I checked with the developers of the Streams API and they say that reducing the amount of memory allocated, even just a little bit, is helpful and so I think this is worth prototyping and measuring.

[RReverser]

I don't have specific usecase where this would be necessary, but yes, BYOB could be interesting for performance reasons as well as for simplifying Wasm bridge code.

One other thing that could be helpful to track here is to allow using SharedArrayBuffer-backed data in WebUSB API.

This is a common issue with Web APIs that they try to protect developers from race condition and tend to restrict accepted typed arrays to non-shared only, but in practice it means that all users of multithreaded Wasm have to allocate a copy of the data they have just to pass it to the Web API, and then implementations like Chromium copy it yet again to send over Mojo or similar bridges to native code.

This is pretty wasteful, especially given that code compiled to Wasm usually has its own logic for dealing with any races and wouldn't have issues with unexpected mutations in practice - even if it did, at worst this would be a logic errors as typed arrays and Wasm memory are already bound-checked.