wasip2 uses wasi:random/random to generate hashmap_random_keys

wasip2 currently still uses (all?) wasip1 implementations internally. The generation of hashmap_random_keys for wasip1 is implemented here:
https://github.com/rust-lang/rust/blob/a32d4a0e822a29a6682e08b75a8df4c29c7fa9f1/library/std/src/sys/pal/wasi/helpers.rs#L109-L117
using the wasi::random_get (https://github.com/WebAssembly/WASI/blob/main/legacy/preview1/docs.md#-random_getbuf-pointeru8-buf_len-size---result-errno) general-purpose function. With the popular wasi-preview1-component adapter crate (https://github.com/bytecodealliance/wasmtime/tree/main/crates/wasi-preview1-component-adapter), this call is mapped to the wasi:random/random wasip2 interface, which must be backed by a secure random source. This is unfortunate as wasip2 Rust code which only uses randomness in hashmaps now required a secure random source when an insecure one would suffice.

In wasip2, there is the separate wasi:random/insecure-seed interface, which is specifically designed to provide DoS protection when initialising a hash map. When the wasip2 implementation is fleshed out, perhaps the hashmap_random_keys function could be implemented with a pseudo-RNG that is seeded with one call to wasi:random/insecure-seed's insecure-seed()?

cc @alexcrichton

Start in library/std/src/sys/pal/wasi/helpers.rs at the hashmap_random_keys implementation and compare it with the WASI preview1-component adapter's mapping of random_get. Read the wasip2 wasi:random/insecure-seed interface and determine how it should seed the hashmap key generator. Done means wasip2 no longer requires the secure random interface solely for hashmap randomization, with the relevant behavior covered by existing project tests.