js: Take a component as input, not interfaces

[alexcrichton]

This commit is the implementation of #314 for the JS host generator.
The commit here covers basically everything in that issue for JS except
it generates a slightly different structure of the JS output. Otherwise
the main highlights are:

• The JS host generator no longer implements the core Generator trait
  since it doesn't really fit in the component-as-input world. For now I
  created an InterfaceGenerator trait since similar functionality is
  used just not precisely the same. I expect that this will get iterated
  on over time as worlds and other host generators take shape.

• The wasmtime-environ crate from Wasmtime itself, typically a "private"
  dependency of Wasmtime, is used to parse the input component and
  generate an instantiate function in JS. Wasmtime does all the heavy
  lifting of creating a linear list of initializers for the component
  and this empowers the generator to simply generate JS that is the list
  of initializers.

• The wit-component crate is used to "extract" the Interface
  descriptions from the input component. This is used to generate type
  information for TypeScript as well as types for lifting/lowering.
  Internally a correlation is done from a lowering/lifting to an
  Interface function to connect the dots when instantiating a component.

Lots of pieces needed updating here such as the runtime tests, the
wit-bindgen CLI tool, and the demo web page. These are all updated for
the new structure of the JS host generator.

Overall this surprisingly went much more smoothly than I expected. With
wit-bindgen being able to extract Interface representations from a
component most of the prior JS host code generation was able to be
reused. Along the way I also felt that the addition of "worlds" would
have relatively obvious insertion points and would be relatively easily
handled in all the places.

The demo and runtime tests are proof enough to me at least that this all
works internally, and this feels like a solid foundation to iterate from
with the addition of worlds and continued support for JS hosts.

[alexcrichton]

Procedurally this is built on #372 and additionally depends on bytecodealliance/wasmtime#5053, so will want to hold off on merging until those are both in.

[pchickey]

review still in progress, just pushing these easy ones

[pchickey]

This is awesome, lets ship it. I spent some time going through this with @guybedford and we satisfied a bunch of curiosity we had about why the generated code looks like it does.