[Spike] Migrate wasm-utils into wasm-instrument

[cspramit]

wasm-utils crate is apparently archived by the owners and wasm-instrument have the same functionality and is maintaned.

[mpapierski]

Some observations:

• gas_injector creates a gas function with an i64 argument instead of i32, so since we’ve already burned gas functions in the global state, we'd have to support both signatures on the host. We shouldn’t burn the preprocessed wasm into a global state anymore as part of 2.0.0 to avoid issues like that in the future, and once that's done, we could migrate to wasm-instrument
• I ported old wasm-utils gas metering rules to their new API, but now one test fails. The new gas cost is 40% higher than the hardcoded expected gas cost, which is a possible blocker for pursuing this. At first glance, it seems gas injector logic is also changed. Need to compare further the source of the old and the new meter to understand it better, as there must be a backward-compatible way of doing this.
• Seems like the stack height injector’s logic is also changed, as my existing tests verifying it’s working are currently failing. Need to compare further the source of the old and the new meter.
• wasmi depends on parity-wasm 0.45.0, but we use 0.42.2. This throws a bunch of compiler errors due to two different versions of parity-wasm used. I hacked a conversion from the newer module to the older one and back to execute the test suite. To avoid hacks, we need to upgrade wasmi to a version that depends on 0.45.0. But wasmi version, which uses 0.45.0, has a lot of breaking changes and is a nontrivial task we could pursue first, possibly before 2.0.0.
• wasm-utils optimizer is gone, and the upstream recommendation is to just use binaryen, which doesn’t offer a similar API but a general shrink level/optimization level compiler-like interface, rather than remove anything not referenced by a vec of exports.
• No externalize_mem API - this one was a simple to fix as it only injects a memory import, to be always able to inject a memory instance to a Wasm module. I copied and pasted the wasm-utils function over to our codebase.

I think it's not worth pursuing the migration before 2.0.0 due to the gas limit injector and stack height limiter changes. We could try:

• As we invested a lot of effort into making sure wasm-utils calls are safe, we could copy over inject_gas and stack_height::inject_limiter and maintain it as-is on our side in the interim.
• Don't burn gas injected into the global state as part of 2.0.0. So an internal gas function that changed signatures wouldn't bother us, and we'd have to support only a single signature in a "gas" function instead two.
• bump wasmi, and parity-wasm to 0.45.0 so we can make future migration easier. We use ancient version of wasmi (0.8.0), but the new is 0.20.0.
• Another spike to check if binaryen compiler has a better optimizer for unused stuff than the removed one from pwasm-utils (it probably is better as a lot of wasm compilers use it under the hood)

CC @georgepisaltu

WIP code is here https://github.com/mpapierski/casper-node/tree/gh-3228-wasm-instrument