Shrink the total size of all fuzzers when built

I ended up going down a pretty long rabbit hole this morning for a number of reasons around our fuzzers. The main conclusion I reached so far is that Wasmtime's fuzzing on oss-fuzz has stopped as of 2022-02-24, which is about a week ago at this point. After [talking with the oss-fuzz folks](https://github.com/google/oss-fuzz/issues/7353) the conclusion is that the likely cause of this is that the size of all of Wasmtime's compiled fuzzers is too large and exceeds the disk space capacity of the machines running the fuzzers. A local build of the oss-fuzz image shows that Wasmtime produces ~6.8G of fuzzers as of right-this-red-hot-second.

The easiest fix to apply for now is to [pass the `--strip-dead-code` option](https://github.com/google/oss-fuzz/pull/7354) to `cargo fuzz`, which disables passing `-Clink-dead-code` which greatly reduces the size of the output directory to 3.4G (~50% reduction). This should hopefully buy us some runway. According to [this](https://github.com/rust-fuzz/cargo-fuzz/commit/86b4889e3e0f6faac8433659bcac08c4b32097c0) linking dead code is intentional and fixes some errors printed out by libfuzzer, but locally I was unable to reproduce those errors and [given the recent introduction of the `--strip-dead-code-flag`](https://github.com/rust-fuzz/cargo-fuzz/pull/260) it seems like it at least works for others, so I'm hopeful that passing this flag will not impact the actual fuzzing process.

In any case though I consider the `--strip-dead-code` argument to be more of a quick fix than a permanent solution. This will continue to limit our ability to add more fuzzers since each new fuzzers is hundreds of megabytes as it statically links all of Wasmtime. My proposed solution to this is to instead have a scheme where the `wasmtime_fuzzing` crate is built as a `dylib` (Rust crate type) which all the fuzzers then link to. Each fuzzer would then individually be quite small and we'd only have one copy of Wasmtime on disk for the build artifacts, probably reducing the output size by another 2-3G or so. There's some [documentation online](https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies) about how we need to be careful about dynamic library dependencies for the fuzzer, but that shouldn't be too hard to codify.

Overall I think this is something we need to fix before adding more fuzzers, but for the time being if https://github.com/google/oss-fuzz/pull/7354 works then we don't need to fix this immediately because we'll be back to fuzzing and have a good deal of headroom since we're 50% of the limit.