`wasm_wave`: Make crate `no_std` compatible

[wilfreddenton]

In a project I'm working on we are using wasm_wave within modules. Ideally we can make these modules compile with no_std but the wasm_wave dep is currently preventing that. For my use-case I am disabling the default wit feature which adds the wit-parser dependency so that crate would not need to become no_std.

Very similar situation to this issues: #3

I'm happy to do this work and can follow the patterns in this PR: #1493

But I want to check with the maintainers first that this is an acceptable change and if they have opinions on how it should be done i.e.

Should a non-default no_std feature or a default std feature that can be disabled be created? Or maybe an alloc feature instead?

What Map object should be used instead of std::collections::HashMap? I noticed that indexmap is a dep but it has the std feature enabled.

[alexcrichton]

@lann you might have more thoughts on this than I.

From my perspective I'm not familiar enough with the crate to know off-hand whether the same strategy for wasmparser would work out for wasm-wave. Much of the time no_std crates do indeed use the alloc crate, and for maps they can be transitioned to BTreeMap as well in some situations too.

[lann]

I'd have to re-familiarize myself with the code to be sure but I don't recall any reason why this wouldn't work with alloc / BTreeMap. Looking at the one use of indexmap I think it could be removed entirely with a slightly different implementation.

[wilfreddenton]

Made a first draft of this at #2401. Since most of the crate doesn't really need std I'm just pulling everything from alloc and core and then anything that depends on wit-parser is behind the wit flag which, when enabled, forces on the new std flag.
Let me know what you think. Thank you!