Add a new wit-smith subcommand

[alexcrichton]

This commit extracts the WIT document generation from the roundtrip-wit fuzzer into a dedicated crate and a dedicated subcommand, wasm-tools wit-smith. This is intended to behave similarly to the wasm-tools smith subcommand but it instead generates a WebAssembly binary-encoded WIT document.

[alexcrichton]

cc @dicej your mention of componentize-py's testing last week inspired me to do this, doubly so after I found your testing script. I think it might actually be good to start using this sort of strategy to improve the testing story around WIT code generators by having a pipeline of "well take this generator, generate bindings, and make sure they work" as a sort of standard practice.

In that sense I was inspired to take what was already preexisting in the roundtrip-wit fuzzer in this repository and clean it up slightly. I'm curious though if you think this shape of feature would be useful for componentize-py or other WIT bindings generator testing? No need to integrate it urgently or anything like that, but I was thinking it'd be good to get onto a trajectory of having shared infrastructure if we can.

[dicej]

Very cool -- this will definitely be useful. In the case of componentize-py, I'm currently generating a bunch of exported functions which call generated, host-provided imports, which echo their parameters in a tuple, and those functions are executed with arbitrary values at runtime to test round-tripping (similar to how we did component type derive macro fuzzing in wasmtime). I'm wondering how something similar might work with wit-smith given there's no obvious way to generate host implementations for arbitrary WIT imported functions, and no way to generate guest implementations for arbitrary exported functions.

Perhaps wit-smith could have an echo mode where it behaves like componentize-py's script, in addition to the default, unconstrained mode. componentize-py could use the former for runtime testing and the latter to at least make sure it generates a valid component with the expected type (but not try to instantiate it and call exports).

[alexcrichton]

Ah yeah that makes sense, and there may not be a ton of overlap in that case now that I think more about it. Seems reasonable though to have that sort of mode!