Add a component-model feature to wasmparser

[alexcrichton]

This commit gates the implementation of the component-model proposal in
wasmparser behind a Cargo feature named component-model. This is
intended to lower the binary size and compile time of this crate in
situations where components are not needed. Additionally this helps
factor logic cleanly between core module and component layers both at
the API and internal levels.

[alexcrichton]

Note that this is built on #1844 for now and is separated out into a few refactoring commits as well (after that PR)

[Robbepop]

I just updated this Wasmi PR to use the new wasmparser v0.219.0 and disable the component-model feature with some nice compilation time reductions:

v0.218.0:

cargo build -p wasmi --profile bench  22.52s user 1.16s system 201% cpu 11.778 total

v0.219.0:

cargo build -p wasmi --profile bench  18.95s user 1.18s system 178% cpu 11.248 total

I looked at cargo tree -d and saw that hashbrown is included (with no-hash-maps) and thought about a solution. It is because of the no-hash-maps crate feature that is used in wasmparser and simultaneously in wasmi_collections.

@alexcrichton What do you think about a small re-design with which it is possible to also put those dependencies (and associated code in wasmparser) behind yet another crate feature? The new design gets rid of the no-hash-maps crate feature and introduces 2 new ones:

• hash-collections: Adds the hash-table based collections to wasmparser.
• prefer-btree-collections: Prefers btree-based collections over their hash-table based counterparts.

These 2 new crate features are additive. 4 cases:

1. Both are disabled: the btree-based collections still exist and are used.
2. Only hash-collections are enabled, then hash-based collections exist and are used.
3. Only prefer-btree-collections are enabled then hash-based collections do not exist and btree-map collections are used.
4. Both are enabled: then hash-based collections exist but btree-based collections are used instead.

Thus btree-based collections always exist while hash-based collections are optional. This is natural for wasmparser because it uses external dependencies for hash-based collections (indexmap) but ships its own implementations for btree-based collections.

To keep semantics the same as before by default only the hash-collections feature is included in the default crate feature set.

This covers all use-cases while also allowing to get rid of the hash-based collections altogether, also from dependency graph. What do you think about this? Is there an even simpler design alternative?

What I like in particular about this design is that crate feature names no longer contain a negation. Negations keep twisting my brain.

[alexcrichton]

That seems like a promising idea yeah! I'm not sure I 100% follow in some points though because there are public types in the wasmparser API, e.g. a set of imports or exports, which can't change types as a result of various features in play, so I think we'd still need the wrappers, right? Part of the problem here as well is that if the std feature is active then there's no need to depend on hashbrown, but if the std feature is disabled the dependency is needed. AFAIK that can't be modeled with Cargo's optional dependencies at this time.

Regardless though I'd be happy to see changes in this regard (I agree on preferring "positive" features) so I'm also happy to review PRs along these lines.

[Robbepop]

Okay good to know. I will hopefully have more time starting next week to dig into this and come up with PRs.