Soundness bug with Send+Sync implementations in the browser

[Michael-F-Bryan]

Describe the bug

It looks like we accidentally introduced a soundness bug in #3556 when adding Send+Sync bounds to things like wasmer::js::Module and wasmer::js::Memory.

Here's one example:

wasmer/lib/api/src/js/module.rs

Lines 48 to 57 in d53b9e2

	// Module implements `structuredClone` in js, so it's safe it to make it Send.
	// https://developer.mozilla.org/en-US/docs/Web/API/structuredClone
	// ```js
	// const module = new WebAssembly.Module(new Uint8Array([
	// 0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00
	// ]));
	// structuredClone(module)
	// ```
	unsafe impl Send for Module {}
	unsafe impl Sync for Module {}

The underlying assumption is that because a type implements structuredClone it's fine to implement Send and Sync.

However, structuredClone only applies when sending values to a worker using postMessage.

If you use any other method to transfer a value to another thread (e.g. channels) then the underlying JsValue will point to the wrong object on that thread's wasm-bindgen "heap" and you'll have a bad time.

Additional context

See the conversation on Slack for more