Change encoding of WIT definitions into Component Model types

[lukewagner]

This PR tweaks the encoding of WIT definitions into component-level types as described in WIT.md. The primary motivation here is to avoid having a special kind of "WIT package" and rather to allow WIT definitions to just be normal (type) definitions inside normal components that can be exported and named like anything else. This allows more-unified registry tooling and also it allows a bit more flexibility for packages to contain both implementation and interface definitions.

[alexcrichton]

@elliottt, @lukewagner, and I talked a bit about this new encoding scheme and have reached the conclusion that a proposed tweak would be to change export-of-instance-type to become export-of-instance. The rationale is not about the design per se but instead relates to https://github.com/bytecodealliance/wasm-tools/issues/1253 where currently wasm-tools doesn't validate export-of-instance-type correctly when the type has resources inside of it. Moving to export-of-instance would sidestep the questions raised there and ideally buy more runway to figuring out how to correctly implement this in wams-tools.

---

As an orthogonal point, though, @elliottt and I also realized that with this encoding scheme then an empty WIT package with no interfaces or worlds can't be encoded. Basically the package name and namespace is lost and there's nowhere to put it. Shall we perhaps consider empty packages invalid from a parser level in that case?

[lukewagner]

Yes, that changes sounds good to me; it also has the nice property of being more symmetric with the imports encoding use, which, quite coincidentally, makes the encoding of the idea in #262 pretty clean. Updated

[lukewagner]

Oh, and to your second point, that's a good point, and one I wrestled with too. Although it's a bit subtle, I think what we can say is that the point of the interface names in the encoding is not to name the package, but, rather, to name the definitions in a way that is later validated to be consistent with the externally-assigned name of the package at the point of publication. So, e.g., we could union two packages into a single component binary; the result wouldn't be publishable as a package (b/c the package-name-consistency validation would fail), but it would be useful as a single-file collection of "all the type info", which I think is useful for some of the future non-publishing workflows we talked about earlier.

If we wanted, we could define a "package metadata" custom section that would include author, email, description, etc, and this might be a natural place for the package name to canonically reside.