Try to put the Wasmi engine internals into its own crate

[Robbepop]

The wasmi crate became very large over the recent years with all the added functionality and the new register-machine engine.

While compilation times are not yet an issue we might want to tackle this problem before it becomes one.
Compared with other crates in the Wasmi workspace the wasmi crate is by far the largest and it would be nice if we could split it up into more smaller crates.

As of today (2024-04-23) the wasmi crate has approx. 51k LoC without comments while its wasmi::engine submodule makes up 44k LoC of the total. It should be noted though that 21k LoC of those 44k LoC are pure test code to verify that the Wasm to Wasmi bytecode translation works correctly.

I am not yet sure if this is going to work out but what we could do is to carve out the entire wasmi::engine module and put it into its own crate. The wasmi crate would then depend on the new wasmi_engine crate and use it to drive execution just like the current wasmi crate uses its internal wasmi::engine submodule to do so.

This issue tracks progress of this work item and accumulates discussion and feasibility studies.

Problems

One problem is that for host function calls the Engine needs to be aware of the Store thus the Store or its internal implementation should reside in the Engine too. So what is ultimately left in the wasmi crate afterwards? Maybe we could move index types such as Func, Global etc. to yet some other crate and entity types such as MemoryEntity could reside in wasmi_engine or even yet another crate that wasmi_engine depends on.

[Robbepop]

This has been implemented in parts by #1152 and #1184.
At this point I am not sure how (technically) viable it is to move even more parts of the engine submodule into their own crates.