Fix Wait/Notify opcode, the waiters hashmap is now on the Memory itself

[ptitSeb]

The Wait/Notify opcodes needs a list a waiters to works.
This list (an hashmap in fact) needs to be on a common object. It makes more sense to have the hashmap being part of the Memory object.

The LinearMemory memory trait has been expanded accordingly, with sensible default, that will behave as if the memory was not shared.
The actuall hashmap in only implemented for VMSharedMemory

[theduke]

One thing to fix, and some recommendations.

I like moving this to the memory.

Note: this can be a separate PR, but we also need some external way to know when a thread goes to sleep (wait) and is woken up (notify).

Moving this to the memory is actually great for that, because now we should be able to add it to the trait, so the behaviour of wait/notify can be customized.

You see any problems with that?

[ptitSeb]

I'm fine with that :)

[john-sharratt]

Hey guys - this is not asynchronous thus it will block execution and cause quite some performance bottlenecks on the WASI implementation with tokio. Have you put consideration into how the thread will be unloaded into an asynchronous context?

[theduke]

@john-sharratt we will add functionality to extend the wait/notify behaviour in the LinearMemory trait, but I haven't in detail thought about how to propagate this .

It will be difficult while also being able to snapshot the stack.

Need to talk/think about this, but that can be done as a followup, not in this PR.

[theduke]

LGTM