Should we add our own wasmi_parse crate to replace wasmparser usage?

[Robbepop]

As the title suggests this is currently an unanswered question.

This issue is about the idea to add a custom Wasm parsing crate to the Wasmi workspace: wasmi_parse
The wasmi_parse crate would replace today's Wasmi's wasmparser uage.

The main reason behind a custom wasmi_parse crate is that it seems that Wasmi's niche needs are somewhat unaligned with most other users of wasmparser. For example:

• Wasmi's niche needs prevent other wasmparser user's use cases:
  • This discusses dissolution of wasmparser's simd feature to no longer be nearly as effective for compile time reduction.
  • Impossible to implement VisitOperator::simd_visitor generically bytecodealliance/wasm-tools#2181
• Wasmi's dependence for a lightweight and efficient parsing solution is not as urgent for others:
  • E.g. in Wasmtime the JIT translation heavily dominates parsing and validation performance whereas in Wasmi it is 50/50 and thus significant.
  • wasmparser: 15-30% performance regressions from v228 -> v229 bytecodealliance/wasm-tools#2180

Advantages

• More control over the features implemented in the Wasm parsing abtractions.
• Wasm parsing could potentially be more specific to Wasmi's unique needs and thus improve performance.
• The wasmparser crate deals with way more than what Wasmi needs, e.g. the component model and legacy features such as the legacy exception handling.

Downsides

• The Wasmi team (me) has to maintain yet another major crate.
• Wasmi no longer profits from upstream improvements so easily.
• It is no longer as easy to help upstream wasmparser with wasmi_parse being its own fork.
• We once had wasmparser-nostd and it was a mess to maintain it, however, unlike wasmi_parse, wasmparser-nostd was never meant to evolve away from wasmparser and be specific to Wasmi's needs.