Consider opting-in to more pedantic Clippy lints about `unsafe` usage

In light of [unsafe code guidelines for Wasmtime](https://github.com/bytecodealliance/wasmtime/pull/11177) and browsing the [list of Clippy lints](https://rust-lang.github.io/rust-clippy/master/index.html) there are a number that we might want to opt-in to. For example:

* [`missing_safety_doc`](https://rust-lang.github.io/rust-clippy/master/index.html#missing_safety_doc) - this would help ensure that `# Safety` sections are available on all `unsafe` functions.
* [`multiple_unsafe_ops_per_block`](https://rust-lang.github.io/rust-clippy/master/index.html#multiple_unsafe_ops_per_block) - this would help ensure that `// SAFETY: ...` documentation for an `unsafe` block is accurately describing just one unsafe operation, not multiple by accident. This might also help over time where new unsafety couldn't get introduced in a block by accident without explaining why it's valid.
* [`undocumented_unsafe_blocks`](https://rust-lang.github.io/rust-clippy/master/index.html#multiple_unsafe_ops_per_block) - this would ensure that all unsafe blocks have a comment explaining their rationale.

To be clear though I do not believe that it would be helpful to blanket require this for the workspace all at once. Writing lots of trivial `// SAFETY` documentation that doesn't do anything more than the obvious is not going to be helpful and will otherwise introduce a lot of noise. Nevertheless though I do think there's a world in which we could perhaps migrate a module-at-a-time to enabling these lints (or maybe even function-at-a-time if modules are too coarse-grained). Over time more and more of the `wasmtime` crate would be held to a higher standard and eventually the entire crate would use these lints (or some subset).