Bring back per-thread lazy initialization (#2863)

* Bring back per-thread lazy initialization

Platforms Wasmtime supports may have per-thread initialization that
needs to run before WebAssembly. For example Unix needs to setup a
sigaltstack and macOS needs to set up mach ports. In #2757 this
per-thread setup was moved out of the invocation of a wasm function,
relying on the lack of Send for Store to initialize the thread at Store
creation time and never worry about it later.

This conflicted with [wasmtime's desired multithreading
story](https://github.com/bytecodealliance/wasmtime/pull/2812) so a new
[`Store::notify_switched_thread` was
added](https://github.com/bytecodealliance/wasmtime/pull/2822) to
explicitly indicate a Store has moved to another thread (if it unsafely
did so).

It turns out though that it's not always easy to determine when a
`Store` moves to a new thread. For example the Go bindings for Wasmtime
are generally unaware when a goroutine switches OS threads. This led to
https://github.com/bytecodealliance/wasmtime-go/issues/74 where a SIGILL
was left uncaught, making it appear that traps aren't working properly.

This commit revisits the decision in #2757 and moves per-thread
initialization back into the path of calling into WebAssembly. This is
differently from before, though, where there's still only one TLS access
on the path of calling into WebAssembly, unlike before where it was a
separate access. This allows us to get the speed benefits of #2757 as
well as the flexibility benefits of not having to explicitly move a
store between threads.

With this new ability this commit deletes the recently added
`Store::notify_switched_thread` method since it's no longer necessary.

* Fix a test compiling

docs/examples-rust-multithreading.md

@@ -129,16 +129,11 @@ some possibilities include:
     `Store::set` or `Func::wrap`) implement the `Send` trait.
 
   If these requirements are met it is technically safe to move a store and its
-  objects between threads. When you move a store to another thread, it is
-  required that you run the `Store::notify_switched_thread()` method after the
-  store has landed on the new thread, so that per-thread initialization is
-  correctly re-run. Failure to do so may cause wasm traps to crash the whole
-  application.
-
-  The reason that this strategy isn't recommended, however, is that you will
-  receive no assistance from the Rust compiler in verifying that the transfer
-  across threads is indeed actually safe. This will require auditing your
-  embedding of Wasmtime itself to ensure it meets these requirements.
+  objects between threads. The reason that this strategy isn't recommended,
+  however, is that you will receive no assistance from the Rust compiler in
+  verifying that the transfer across threads is indeed actually safe. This will
+  require auditing your embedding of Wasmtime itself to ensure it meets these
+  requirements.
 
   It's important to note that the requirements here also apply to the futures
   returned from `Func::call_async`. These futures are not `Send` due to them