Allow cranelift and satellite crates to be able to build in full no-std mode

[stevefan1999-personal]

This PR is the part 1 of the 2 to convert wasmtime into no-std build capable runtime, that makes Cranelift crates to be able to build in fully no-std mode with hopefully minimal code changes, which is needed because https://github.com/wasmi-labs/wasmi lacked so many features I needed.

The first step is to enable Cranelift and its satellite crates to be no-std capable, and since a platform is no longer a guarantee, which means that only Pulley interpreter is available for no-std mode, and thus no need for virtual memory support, so I added a Vec arena backed memory allocator for the "JIT" (but which honestly should be a no-op).

This is also needed because I'm also writing a C compiler, and I don't really want each unit tests to invoke the codegen which sometimes exhitbits strange memory protection error during normal cargo test. My educated guess for that is because of the allocated JIT memory map is so frequent, but the memory protection region has overlapped with ongoing page fault, so the internal virtual memory allocator can't keep up, causing general memory protection error. Although I can sidestep it with cargo nextest which runs each test as an independent process for now, but I'm also curious why that would happen.

I also opted for using libm entirely for the Cranelift interpreter (what's the difference between this and Pulley by the way?), that a deeper research revealed that the fundamental reason for the seemingly faulty fma behavior is due to different ISA platforms implementations, a close analogy for that is the different implementation of long double in x87 and in ARM NEON, which I hope could make things easy to explain. As such, I would suggest just normalize it by using libm anyway.

[bjorn3]

I feel like if you want a no_std JIT, you should make your own cranelift_module::Module implementation instead tailored to the constraints of your OS.

[alexcrichton]

Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a no_std environment? Or are you looking to get the entire suite of Cranelift crates separately running in a no_std environment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.

[stevefan1999-personal]

Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a no_std environment? Or are you looking to get the entire suite of Cranelift crates separately running in a no_std environment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.

Okay so it is two fold:

1. Use Cranelift for the C compiler, which is written in no_std
2. Having a wasmtime build that I can run universally (and better if it comes with WASI support), such that Cranelift may or may not have JIT over that platform. The most important one is i386 support (or technically i686)

The reason I have to do 1. is that the C compiler should run in wasm and i686, basically any platforms that Rust could technically support. With enough hacks, maybe even on powerful ESP32s in the future. In fact, 2. is also part of the reason because I need a virtual file system if I compile it to wasm for browser access, may or may not be using WASI as a middle layer. I'm aware of that Rust's std do support WASI to some extent, but I prefer not to because that means I have to choose for using the legacy proposal or the component model.

But I agree that it is okay to downsize the scope of the PR to break it down one by one, its just a little bit entangled.

[alexcrichton]

Ok sounds reasonable. I'd recommend, yes, splitting this PR up as it's a bit too sprawling to review at this point. What I'd reccommend is going crate-by-crate to get things no_std compatible. Since this is your first contribution I'd recommend doing something on the small-to-mid size first to learn how CI/review/style will work here, and then it should be easy to scale up to other crates after that.