Preserve locals before entering control flow during compilation

[Robbepop]

This supposedly fixes #934.

This is still in draft due to the following reasons and ToDos:

• Adjust all translation tests that are failing due to changes in the Wasmi codegen and check if they are still valid.
• Add more translation tests:
  • Test for loop control flow.
    • I couldn't find a single test case that was invalid before these changes but valid after. My theory is that for loop control flow structures local preservation is not needed because it is not possible to conditionally skip local manipulation without using block or if within the loop body somewhere. Someone please proof me wrong.
  • Tests with more inputs encoding CopySpanNonOverlapping and CopyManyNonOverlapping.
  • Tests with input parameters for block and if.
  • Add a test that triggers usage of the large stack mode.
• Improve efficiency of the WIP implementation introduced in this PR.
  • The current WIP implementation is very wasteful with memory allocations and the old data structures to manage the locals on the stack are not ideal for their current job. I already know how to fix both problems but the work needs to be done prior to merging to avoid creating new attack surfaces.
  • Avoid unnecessary memory allocations.
  • Introduce new data structure to efficiently handle local variables on the compilation stack.
  • Add len_locals to Providers stack to act as a fast bail out condition for the common case when no locals need to be preserved.
  • Preserve locals in reserve order of their appearance to avoid a non-critical attack vector in the inline mode of preservation. It is non-critical since the inline mode is used for very limited stack sizes only.
  • Replace the BTreeMap in preserve_all_locals_inplace with an ArrayVec and linear search. This avoids heap allocations and won't introduce an attack vector since preserve_all_locals_inplace is guaranteed to operate on very small sets of values.
• Merge copy instructions resulting from the new codegen introduced in this PR.
  • This is an optimization that can easily be applied. Although given that it is only an optimization we should first make sure that everything is correct and working.
  • This uses the fact that preservation register slots are usually adjacent to each other and thus we can easily use copy2 or copy_many instructions instead of having multiple copy instructions for each preserved local.
• Conduct benchmarks to show that the new Wasmi codegen does not significantly regress performance.
  • Performance benchmarks conducted so far locally show no significant impact.
• Run the differential fuzzer in order to see if the changes introduced in this PR are actually generally correct.
  • Couldn't run the fuzzer due to external problems: Preserve locals before entering control flow during compilation #945 (comment)

Follow-Up PRs

• The new codegen might result in transitive copies which we can eliminate.
  • Issue: Optimization: Fuse transitive copies #946
• Find out what causes the new memory-ouf-of-bounds access problems with execution of the ffmpeg.wasm binary.
  • This could either be a correctness issue in this PR or a hint to yet another unrelated bug.

[Robbepop]

Benchmarks performed locally show that performance does NOT significantly regress for both translation and execution with the changes introduced in this PR.

[Robbepop]

Unfortunately I cannot run the Wasmi fuzzer due to some weird nightly related issue with some dependencies:

error[E0635]: unknown feature `stdsimd`
  --> /Users/robin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ahash-0.8.6/src/lib.rs:99:42
   |
99 | #![cfg_attr(feature = "stdsimd", feature(stdsimd))]

Note that ahash is not imported from within any Wasmi dependency. So this might be related to either cargo-fuzz, Wasmtime or the outdated WASI dependencies. However, building Wasmi WASI standalone on nightly works fine.

[Robbepop]

I just clarified here that I am going to merge this PR as is and will start with further investigation on the ffmpeg.wasm issues until fixed entirely.

[Robbepop]

To summarize: The fix implemented in this PR was relatively straight forward to implement. The majority of the work in this PR was focused on ensuring quality of the code and to make the new code resist malicious attackers and making it scalable for the new demands.