Convert translation tests to Wast tests #1439
Description
Wasmi has tons of translation unit tests that are deeply connected to how Wasmi encodes Wasm instructions.
On the one handside having these tests is great and helped a lot with building the (then) new Wasmi register-bytecode translation. However, its very tight coupling with Wasmi's instruction encoding is also hindering development of new, better instruction encoding since we'd have to adjust all the translation unit tests or even re-write them substantially.
An example for this is a new Wasmi bytecode encoding scheme that no longer uses an enum but instead encodes Wasmi bytecode instructions as raw bytes. This is what most other efficient interpreters do (Stitch, Wasm3, WAMR, Pulley etc..) but it is also kinda unsafe to decode those which is why Wasmi is using an enum: it is the simpler and safer approach. But is it really simpler? Using an enum is a huge trade-off because one is also constrained quite a bit more when it comes to bytecode design. Every single Wasmi bytecode also is packed in 8-bytes and has 2 bytes or discriminant, which is also true for bytecode parameters - thus a lot of bytes are wasted there. Furthermore a big pain point is that it is impossible to encode more than 32-bit (or 48-bit) values at a time. This has led to Wasmi encoding 64-bit ptr and offset values for load and store instructions as 32-bit low-high pairs. This is not only harder than simply encoding and decoding the 64-bit value but also less efficient, definitely not simpler and more error prone.
Thus this issue tracks progress of converting some or most of the translation unit tests to Wast tests.
The downside is that this no longer tests Wasmi translation as in-depth as the translation unit tests but provides a more stable testing ground and in particular tests that won't stand in the way of future developments.