wasmparser: minimize diff for no_std support mirrors

[Robbepop]

This PR does not introduce no_std support to the wasmparser crate.
Instead it just simplifies the process of supporting a no_std mirror of the wasmparser crate by minimizing the required diff.

This also replaces Hash{Map,Set} usage in the wasmparser validator with BTree{Map,Set} since those are not attackable in no_std environments. I saw absolutely no difference in the benchmarks. Using BTree{Map,Set} also leads to more deterministic runtime behavior in general.

@alexcrichton Many projects would love to use this high quality and battle tested Wasm parsing and validation crate in a no_std environment so I thought about a solution that fits those projects while not putting a burden on the maintainers (you). This PR just minimizes the diff needed to add trivial no_std support to wasmparser but does not actually introduce no_std support. With this PR it will become very easy to maintain a no_std fork of wasmparser and keep it in sync. I'd be happy to know how you feel about this idea.

Link to no_std wasmparser fork: https://crates.io/crates/wasmparser-nostd

[alexcrichton]

Personally I do not think a PR like this is right to merge into wasmparser, it's basically getting all the downsides of "no-std support" without actually supporting it in this crate, which seems like an odd place to be for me. The downsides I personally see are:

• Non-standard import paths (e.g. take-your-pick of alloc or core)
• Non-standard choices of collections (e.g. switching Hash* to BTree*)
• No testing on CI that this state is maintained
• Non-standard imports of standard types like String and Vec which are otherwise expected to be in the prelude

I understand how "supporting no-std" would basically be putting #![no_std] at the top of the crate with this patch, but that's a project level decision which currently AFAIK has said won't be supported in wasmparser at this time.

[Robbepop]

Personally I do not think a PR like this is right to merge into wasmparser, it's basically getting all the downsides of "no-std support" without actually supporting it in this crate, which seems like an odd place to be for me. The downsides I personally see are:

* Non-standard import paths (e.g. take-your-pick of `alloc` or `core`)

* Non-standard choices of collections (e.g. switching `Hash*` to `BTree*`)

* No testing on CI that this state is maintained

* Non-standard imports of standard types like `String` and `Vec` which are otherwise expected to be in the prelude

I understand how "supporting no-std" would basically be putting #![no_std] at the top of the crate with this patch, but that's a project level decision which currently AFAIK has said won't be supported in wasmparser at this time.

Thanks for your reply! I totally get what you are saying and won't bother you anymore with this no_std thing. Will try to maintain the no_std fork of wasmparser as good as I can myself. I am closing this PR now.