Switching to a faster hashmap implementation

#### Feature

Would it be possible to have Wasmtime use a faster implementation for hashmaps and hashsets?

#### Benefit

When benchmarking Wasmtime 42.0.2 compared to Wasmtime 41.0.4 for some of our workloads, I noticed a ~14% regression in terms of wall clock time and estimated cycles. When I update `crates/environ/src/collections.rs` to use `hashbrown` instead of the standard library hashmap and hashset based off undoing part of #12509, that regression drops to ~7%. Our use-case for Wasmtime is in a latency sensitive environment.

#### Implementation

Naively, would it be possible/advisable to use `hashbrown` or `fxhash` as the hashmap and hashset implementations when `std` is enabled until collections which are able to handle OOMs are in place? Given they perform faster than the standard library hashmaps and hashsets and I don't think we need the cryptographic security in the standard library's implementations.

#### Alternatives

Maybe a configurable hash implementation? We're willing to tolerate OOMs hypothetically causing a process abort if it reduces the amount of the performance regression we're seeing.