Integrate worlds into the Rust & JS generators

[alexcrichton]

The initial goal of this PR was to generalize the work in the JS generator to enable migrating the Python generator to the same infrastructure. In doing so, however, it created a trait to process a world as defined today: a list of imports, a list of exports, and an optional default interface. I wanted to prove out this trait and its usefulness and so I opted to migrate the Rust guest and host generators to this trait as well.

This ended up being much larger than intended, but all of this I believe is inevitably needed for #314 or worlds in general. To be clear worlds do not yet exist in wit-bindgen but this PR aims to create a "hole" in wit-bindgen where a world would clearly fill. To that end the various changes implemented in this PR are:

• Boilerplate code in the JS code generator was reduced and moved to the wit-bindgen-core infrastructure. The goal here was to remove the need to hardcode in the JS code generator what will also be required in the Python code generator. This created the ComponentGenerator trait which is specifically tailored for instantiating a single component.

• The new ComponentGenerator also inherits from a new WorldGenerator trait. This is designed to be the new defacto interface for all code generators. There's still some existing ones using "legacy worlds" which is the old Generator trait but my plan is to eventually delete that once all generators have been migrated. The WorldGenerator trait takes a ComponentInterfaces argument which is the current implementation understanding of a world.

• The guest Rust generator was updated to the new WorldGenerator trait. Similarly the host Wasmtime generator was updated to this new trait. This involved quite a bit of code movement but it also ended up filling out some novel new features. For example it's now more integrated to create exported instances from Rust guests or possible to consume these instances from Rust hosts. Overall the end-to-end representation of a world should be more filled out now.

• The guest Rust generator's way of modeling exports has changed to use standalone by default. I've removed the standalone option here and opted to always have a macro which generates the no_mangle functions.

Lots of fiddly bits around the Wasmtime and the Rust guest generators have changed. Everything prior should still be possible and with even more now that the full expressiveness of our current world representation is supported. It's probably best to review the test changes here to see how things work.

I'd also like to specifically call out that the old Rust import! and export! macros are now removed. There's now only one generate! macro. Eventually this is intended to be generate!("my-world.wit") but we don't have a parser for worlds right now so the next-best thing is that you're required to do generate!({ ... }) with manual import, export, and default options. This is not intended to be ergonomic or even easily understandable at this time, it's just intended to work and last through the transition to worlds.

Overall to reiterate, the goal of this PR is to create a round hole for the round peg of worlds to slot into. There's a number of locations where ergonomics and easy-to-understandability are left on the table because a single concept of worlds in *.wit files should solve it. Furthermore this does not address issues such as sharing types across interfaces, that's left for future refactorings.

[pchickey]

This is a big enough diff that I can't verify every line of it, but as we discussed, the code transformation that happened here is in the correct direction, and I trust that since the tests are passing that this is correct.