Add tests for the interface types output of wasm-bindgen (#1898)

* Add tests for the interface types output of wasm-bindgen

This commit expands the test suite with assertions about the output of
the interface types pass in wasm-bindgen. The goal here is to actually
assert that we produce the right output and have a suite of reference
files to show how the interface types output is changing over time.

The `reference` test suite added in the previous PR has been updated to
work for interface types as well, generating `*.wit` file assertions
which are printed via the `wit-printer` crate on crates.io.

Along the way a number of bugs were fixed with the interface types
output, such as:

* Non-determinism in output caused by iteration of a `HashMap`

* Avoiding JS generation entirely in interface types mode, ensuring that
  we don't export extraneous intrinsics that aren't otherwise needed.

* Fixing location of the stack pointer for modules where it's GC'd out.
  It's now rooted in the aux section of wasm-bindgen so it's available
  to later passes, like the multi-value pass.

* Interface types emission now works in debug mode, meaning the
  `--release` flag is no longer required. This previously did not work
  because the `__wbindgen_throw` intrinsic was required in debug mode.
  This comes about because of the `malloc_failure` and `internal_error`
  functions in the anyref pass. The purpose of these functions is to
  signal fatal runtime errors, if any, in a way that's usable to the
  user. For wasm interface types though we can replace calls to these
  functions with `unreachable` to avoid needing to import the
  intrinsic. This has the accidental side effect of making
  `wasm_bindgen::throw_str` "just work" with wasm interface types by
  aborting the program, but that's not actually entirely intended. It's
  hoped that a split of a `wasm-bindgen-core` crate would solve this
  issue for the future.

* Run the wasm interface types validator in tests

* Add more gc roots for adapter gc

* Improve stack pointer detection

The stack pointer is never initialized to zero, but some other mutable
globals are (TLS, thread ID, etc), so let's filter those out.

crates/wasm-conventions/src/lib.rs

@@ -9,7 +9,7 @@
 #![deny(missing_docs, missing_debug_implementations)]
 
 use anyhow::{anyhow, bail, Error};
-use walrus::{GlobalId, GlobalKind, MemoryId, Module, ValType};
+use walrus::{GlobalId, GlobalKind, MemoryId, Module, ValType, InitExpr, ir::Value};
 
 /// Get a Wasm module's canonical linear memory.
 pub fn get_memory(module: &Module) -> Result<MemoryId, Error> {
@@ -39,21 +39,19 @@ pub fn get_shadow_stack_pointer(module: &Module) -> Result<GlobalId, Error> {
         .iter()
         .filter(|g| g.ty == ValType::I32)
         .filter(|g| g.mutable)
+        // The stack pointer is guaranteed to not be initialized to 0, and it's
+        // guaranteed to have an i32 initializer, so find globals which are
+        // locally defined, are an i32, and have a nonzero initializer
         .filter(|g| match g.kind {
-            GlobalKind::Local(_) => true,
-            GlobalKind::Import(_) => false,
+            GlobalKind::Local(InitExpr::Value(Value::I32(n))) => n != 0,
+            _ => false,
         })
         .collect::<Vec<_>>();
 
     let ssp = match candidates.len() {
         0 => bail!("could not find the shadow stack pointer for the module"),
-        // If we've got two mutable globals then we're in a pretty standard
-        // situation for threaded code where one is the stack pointer and one is the
-        // TLS base offset. We need to figure out which is which, and we basically
-        // assume LLVM's current codegen where the first is the stack pointer.
-        //
         // TODO: have an actual check here.
-        1 | 2 => candidates[0].id(),
+        1 => candidates[0].id(),
         _ => bail!("too many mutable globals to infer which is the shadow stack pointer"),
     };