Add support for #![no_std] to the wasmtime crate

[alexcrichton]

This commit is the final technical piece of #8341 which makes the wasmtime crate itself compatible with #![no_std]. This means that the crate can now be compiled on targets that don't have std when the activated features are a subset of {runtime, gc, component-model}. Support for Wasmtime requires an implementation of wasmtime-platform.h which is something I'd like to also start moving to release artifacts after this as well.

This PR is split into a series of commits with the final one being the "big one" and the others are minor refactorings leading up to it. The major changes made here are:

• The "custom" platform of Wasmtime is now enabled by default if nothing else is applicable. This means that there's no opt-in required for no_std support.
• Embedders can now define a custom feature detection function, for example "does this host support AVX". This is because the default implementation uses the standard library while that's not available with no_std.
• Internal idioms in wasmtime have change to be similar to previous commits for wasmtime-environ and other crates, for example. For example imports come from core and alloc and there's a custom prelude for core + alloc bits and pieces.
• Wasmtime now unconditionally uses hashbrown::HashMap for some items such as Linker and GC sets.
• The wasmtime crate has a few "custom synchronization primitives" which have real implementations backed by other crates in std mode or "dummy" implementations in no_std mode that effectively assert for no contention. This might require updates to wasmtime-platform.h in the future instead.
• Libcall intrinsics for float-related functionality are implemented with the libm crate in no_std mode. In std mode they still use standard library methods.

The main remaining piece I'd like to tackle after this is an update of the no_std documentation for Wasmtime. The page is outdated now and could use some updates. I'll also note that I still have yet to test all these changes beyond what CI is already doing. We don't actually test no_std mode in CI, only that it builds. If anything comes up though I'll work through that in follow-ups.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[abrown]

Undefined behavior... in Wasmtime? I thought we could be pretty sure we'd get a SIGILL or the like?

[alexcrichton]

I'll admit I don't necessarily fully understand this, but my reasoning here is derived from Rust's stance that executing intrinsics your CPU doesn't have support for is undefined behavior. There was a fair amount of discussion about this when first stabilizing SIMD in Rust and I believe the general rationale boils down to:

• There's not an ironclad guarantee that unsupported instructions raise a SIGILL for all unsupported instructions. (at least at the time what was considered was all possible extensions to all possible ISAs)
• There can be "compiler weirdness" where once a feature is enabled it has subtle changes in other parts like assemblers and other chosen instructions which can cause subtle incompatibilities on systems that don't support the instructions.

Overall I don't think that there's a super simple "this is why it's unsafe" thing I can point to to justify this. I am relatively confident in saying, though, that we're probably not guaranteed a SIGILL for all possible encodings of all instructions we could use on all architectures. Coupling that with this is a niche method most won't use is mostly why I figured it'd be ok to mark this as unsafe

[bjorn3]

lzcnt is encoded as rep bsr, which has a redundant prefix. Redundant prefixes tend to be ignored, but are not guaranteed to be. As such lzcnt is interpreted by older cpu's as bsr. This bit me once in cg_clif: rust-lang/rustc_codegen_cranelift#951 (comment) See also https://stackoverflow.com/questions/25683690/confusion-about-bsr-and-lzcnt/43443701#43443701

[fitzgen]

(Taking a look, might be a little while to get through everything here)

[fitzgen]

ship it!

[fitzgen]

Why is std okay to use here? Shouldn't this use the wasmtime_tls_{get,set} stuff?

[fitzgen]

I guess if we are on unix then we know we have std available?

[alexcrichton]

Yeah that was my thinking, on platforms that are known to have the standard library we go ahead and just import from the standard library. Things will get a bit messier otherwise because it's not a great experience for Wasmtime to depend on #[repr(C)] symbols silently so I'm hoping to keep it to a minimum.