Investigate using a wasm interpreter for M2.2

[Stebalien]

E.g., https://github.com/paritytech/wasmi.

AOT compilation can be a bit problematic for untrusted smart contracts:

1. The runtime of wasm "blocks" will depend on how they compile to native code. There are concerns that a malicious actor could come up with pathological wasm bytecode that has a slow execution time with respect to the gas charged by our gas model.
2. AOT compilation is expensive and time consuming. At the very least, it'll need to be asynchronous (and parallel).
3. AOT compilation is architecture dependent so it can't happen inside an actor. That makes it difficult to account for in the gas model and potentially opens us up to compiler bombs.

The alternative is interpretation. Ideally, a wasm interpreter inside wasm (same as we run an EVM interpreter inside wasm). The obvious downsides are:

1. A wasm interpreter will be significantly slower than AOT compilation. However, it should still be significantly faster than the EVM.
2. Running the wasm interpreter inside wasm will add even more overhead. But it also adds quite a bit of security and may allow us to remove some runtime checks from the interpreter.

It may also be possible to default to interpretation, upgrading to AOT/native once the network has compiled the actor to native and performed some validation.

[Stebalien]

Looking at other networks:

• NEAR uses wasmer with the single-pass compiler.
• Substrate uses wasmi inside wasmtime.

[Stebalien]

Ok, it looks like winch (wasmtime's single pass compiler) is making good progress (https://www.youtube.com/watch?v=bj8SUKUg0BQ). If we go this way:

• We'll have to benchmark its runtime.
• We'll likely need two sets of gas charging rules, one for winch, one for cranelift. User defined wasm actors will use the winch rules, "builtin" and/or blessed ones will use the cranelift rules.
• Ideally, we'd develop some system for blessing modules.

[Stebalien]

Discussion https://github.com/filecoin-project/FIPs/discussions/779