Remove Send and Sync from wasmer types backed by JavaScript objects

[Michael-F-Bryan]

This fixes a soundness bug introduced in #3556 which added 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.

Fixes #4158.

[Arshia001]

Just a small nit: assert_not_implemented!(Instance: !Send + !Sync); sounds like a double negative. so one might initially expect Instance to not implement !Send, i.e. that Instance should be Send. I don't have suggestions for alternate syntax though.

[theduke]

Side note: should't clippy have required a Safety: ... comment here?

[theduke]

LGTM

Although: this is technically a breaking change, and would require a 5.0...

Although we can probably get by with just ignoring this here, since it is basically a bug fix.

[theduke]

Can we keep a comment on all assert_not_implemented usage points so future readers know what's going on here?

[syrusakbary]

This PR looks great, but it will require further rework on WASIX to make it work with this changes