Implement the Wasm `memory64` proposal

[Robbepop]

This is about adding support for the memory64 Wasm proposal.

The memory64 Wasm proposal is already in Phase 4 since some time and thus full stabilization can be expected to happen soon.

Having memory64 support in wasmi would improve alignment with Wasmtime, and allow to use Wasmi for Wasm binaries that have been compiled to memory64 (obviously). However, it would also allow to use Wasmi for Wasm binaries that require more than 4GB of linear memory to properly execute which might be a niche use-case given that Wasmi is an interpreter but there still might exist some use cases for it.

[Robbepop]

An issue that I have encountered while trying to implement the adjusted load and store instructions for the Wasmi bytecode is that ideally we want a better encoding scheme. Right now, Wasmi is using a purely enum based approach to encode all instructions, including their instruction parameters. With a 16-bit enum discriminant this means we waste 16-bit of memory for every instruction parameter encoded this way. With the memory64 proposal the offset parameter may be 64-bit long which is a bit troublesome with the current encoding since I was not able to find an efficient encoding. If we had a union based instruction encoding I was able to find a decent enough encoding.

A union based encoding would look roughly like this:

//// A Wasmi bytecode instruction with some of its parameters.
enum Instruction {
    I32Add { .. },
    Load32 { .. },
    Store32 { .. },
}

/// A parameter or set of parameter for a single instruction.
struct Parameter([u8; 64]);

/// Either a Wasmi bytecode instruction or a set of parameters for the previous intruction.
union InstructionOrParameter {
    instr: Instruction,
    param: Parameter,
}

Obviously Instruction and Parameter may be defined differently. For example we could define Paramter as a union, too. While this representation would solve the issue that every instruction parameter wastes 16-bit and thus also solves the problem stated above, this would introduce a significant amount of unsafe code to the decoding of instructions which affects both the Wasmi executor as well as the Wasmi translator. The Wasmi tranlator is affected because some optimizations require to decode Wasmi instructions in order to apply optimizations and this encoding would seriously impact simplicity of the translator and introduce lots of unsafe Rust code in it.