Formalize stance on imported and exported components

Currently my plan for the initial implementation of the component model is to not support either importing a component from the host or exporting a component to the host. Internally a component may export and import components but this can't bubble all the way up to the host. My current plan is to write down errors for when this case arises which point to this issue.

I'm filing this to track an "official" stance in a sense where we should either commit to this implementation detail or we should figure out how to implement this. At this time avoiding importing or exporting components is a massively simplifying detail for the implementation of the component model.

* If a component were to be imported it means that the component could be instantiated and then used internally, notably with fused adapters. This hinders the knowledge we have at compile-time to the point where we can't generate a fused adapter until runtime when the component is instantiated. This goes against Wasmtime's goal of being able to run code without a compiler runtime.

* If a component were to be exported then a `Component` would need to be produce-able for any internal component found. Currently we rely on this not happening and producing a fully "inlined" component representation of how to instantiate everything internal in a component. If internal components could be exported then such inlining could possibly result in $O(n^2)$ initializer instructions. This is probably easier to surmount than the previous point.

No files, tests, or entry points are named. Start by reviewing the component-model constraints described here, especially host imports, host exports, fused adapters, and inlining; done means the project has an official stance and the resulting behavior or implementation path is documented.

Written by the indexing model from the issue text.