Support custom scheduling of WASM threads

#### Feature

As far as I could tell, the current implementation of shared memory and in particular the atomic_wait instructions will eventually block the calling thread (https://github.com/bytecodealliance/wasmtime/blob/b583c54fda13b53dea362861125dd1e2ced1381d/crates/runtime/src/parking_spot.rs#L169). This makes it impossible (I think) to implement custom scheduling of WASM threads, leaving control to the OS.

#### Benefit

Being able to fully control WASM thread scheduling would allow some interesting usecases for embedders:
- deterministic concurrent-but-not-parallel executions (by implementing a scheduler that cycles between non-waiting threads after a certain amount of fuel is consumed in a controlled way)
- debugging utilities for multi-threaded code that explore different execution orders to catch race conditions
- (maybe?) execution of multi-threaded WASM code without OS threads assuming that the wasmtime-fiber implementation is adapted

#### Implementation

My first idea would be to (optionally) modify the SharedMemory implementation of atomic_wait/atomic_notify to instead behave similarly to the implementation of [fuel_async_yield_interval](https://docs.wasmtime.dev/api/wasmtime/struct.Store.html#method.fuel_async_yield_interval), yield control back to the caller and have them figure out how to do scheduling and when to resume the WASM thread.

#### Alternatives

I believe it should be possible to implement this behaviour also by replacing the calls to the atomic instructions with call to user-specified async `Func`s, which might possibly have better ergonomics (in principle, such a modification could be done without explicit support from wasmtime itself)