Expand doc section about "what about #![no_std]?"

This commit expands the `#![no_std]` section of the documentation with
an FAQ-style set of words which explains in more detail about why we
don't support `#![no_std]` at this time, and how we can support it in
the future.

Author: alexcrichton

docs/stability-platform-support.md

@@ -42,3 +42,71 @@ cases for for what `#[no_std]` might entail, so if you're interested in this
 we'd love to hear about your use case! Feel free to [open an
 issue](https://github.com/bytecodealliance/wasmtime/issues/new) on the
 `wasmtime` repository to discuss this.
+
+This is a common question we are asked, however, so to provide some more context
+on why Wasmtime is the way it is, here's some responses to frequent points
+raised about `#![no_std]`:
+
+* **What if my platform doesn't have `std`?** - For platforms without support
+  for the Rust standard library the JIT compiler of Wasmtime often won't run on
+  the platform as well. The JIT compiler requires `mmap` (or an equivalent), and
+  presence of `mmap` often implies presence of a libc which means Rust's `std`
+  library works. We're interested in running Wasmtime without a JIT compiler in
+  the future, but that is not implemented at this time. Implementing this will
+  require a lot more work than tagging crates `#![no_std]` as well! The Wasmtime
+  developers are also very interested in supporting as many targets as possible,
+  so if Wasmtime doesn't work on your platform yet we'd love to learn why and
+  what we can do to support that platform, but the conversation here is
+  typically more nuanced than simply making `wasmtime` compile without `std`.
+
+* **Doesn't `#![no_std]` have smaller binary sizes?** - There's a lot of factors
+  that affect binary size in Rust. Compilation options are a huge one but beyond
+  that idioms and libraries linked matter quite a lot as well. Code is not
+  inherently large when using `std` instead of `core`, it's just that often code
+  using `std` has more dependencies (like `std::thread`) which requires code to
+  bind. Code size improvements can be made to code using `std` and `core`
+  equally, and switching to `#![no_std]` is not a silver bullet for compile
+  sizes.
+
+* **The patch to switch to `#![no_std]` is small, why not accept it?** - PRs to
+  switch to `#![no_std]` are often relatively small or don't impact too many
+  parts of the system. There's a lot more to developing a `#![no_std]`
+  WebAssembly runtime than switching a few crates, however. Maintaining a
+  `#![no_std]` library over time has a number of costs associated with it:
+
+  * There needs to be CI to ensure that when compiled with the right flags the
+    library does not actually use the Rust standard library. Currently there is
+    no stable way to do this in Rust, meaning that although a library may be
+    `#![no_std]` at one point in time it's easy to add a dependency that
+    accidentally sneaks in the `std` crate later.
+
+  * Idioms in `#![no_std]` are quite different than normal Rust code. You'll
+    import from different crates (`core` instead of `std`) and data structures
+    have to all be manually imported from `alloc`. These idioms are difficult to
+    learn for newcomers to the project and are not well documented in the
+    ecosystem. This cost of development and maintenance is not unique to
+    Wasmtime but in general affects the `#![no_std]` ecosystem at large,
+    unfortunately.
+
+  * Currently Wasmtime does not have a target use case which requires
+    `#![no_std]` support, so it's hard to justify these costs of development.
+    We're very interested in supporting as many use cases and targets as
+    possible, but the decision to support a target needs to take into account
+    the costs associated so we can plan accordingly. Effectively we need to have
+    a goal in mind instead of taking on the costs of `#![no_std]` blindly.
+
+* **How can Wasmtime support `#![no_std]` if it uses X?** - Wasmtime as-is today
+  is not suitable for many `#![no_std]` contexts. For example it might use
+  `mmap` for allocating JIT code memory, leverage threads for caching, or use
+  thread locals when calling into JIT code. These features are difficult to
+  support in their full fidelity on all platforms, but the Wasmtime developers
+  are very much aware of this! Wasmtime is intended to be configurable where
+  many of these features are compile-time or runtime options. For example caches
+  can be disabled, JITs can be removed and replaced with interpreters, or users
+  could provide a callback to allocate memory instead of using the OS. The
+  ambitious goals of Wasmtime take time and energy to implement, however, so we
+  need help from others in order to prioritize what's most important to tackle.
+  This is sort of a long-winded way of saying that Wasmtime on the surface may
+  today look like it won't support `#![no_std]`, but this is almost always
+  simply a matter of time and development priorities rather than a fundamental
+  reason why Wasmtime *couldn't* support `#![no_std]`.