Implement initial optimizing compiler backend: project wazevo

[mathetake]

the description here will be updated over time

This issue is the first tracking issue for our frequently requested feature: the optimizing compiler backend. For background, see #777 (comment).

The ultimate goal is to develop the optimizing compiler backend which has support for arm64 and amd64 and has an equivalent performance as the state-of-the-art compilers like wasmtime or wasmer. But that work is never-ending considering that every compiler evolves over time.

Thus, this issue exists for tracking the work around building the foundation for the never-ending iterative development of our new optimizing compiler.

Goal (to close this issue):

1. Develops the new optimizing compiler backend packages in a way that anyone can simultaneously add optimizations and do an experiment on the backend -- this requires not only the proper abstraction but also thorough code documentation on the rationale of any non-trivial logic. Cite the research papers etc as much as possible in the code.
2. No third-party dependency - we previously thought about re-using Wasm-compiled Cranelift and embedding it in wazero to emit machine codes, but that would be more problematic in various ways plus that it contradicts our "zero" dependency policy even if it is just a binary embedding. Therefore everything will be written entirely from scratch in Go.
3. Passes all the Wasm V1/V2 specification test on arm64.
4. Ensures deterministic compilation (via optional testing)
5. Running spectests against regalloc under high register preasure (by tweaking allocatable registers), and ensure that the impl is stable regardless of the available registers
6. Pass all the wazero tests run against the current backend and interpreter.

Non-Goal

• amd64

Note

• I am not planning to reuse any portion of the current single-pass compiler code, so for those easger to contribute, please fight your urge to do so until my first PoC is out (I am expecting it up within July).
• Due to the limitation posed by go runtime, the resulting backend may not be the fastest for some cases, but in anyway no one should expect it to win all bench cases. Even after this finishes, some can find a losing case for sure.

[mathetake]

So we call this new backend wazevo for convenience like a prefix to all related PRs etc because "new optimizing compiler" is verbose. But it's just temporarily used and we can change it later whenever we want and necessary.