More options for deriving worlds

[sunfishcode]

Currently one can use include to derive one world from another, however I've been finding myself wanting more ways:

• include_imports - Like include, but only includes imports
• include_exports - Like include, but only includes exports
• include_imports_exported - Like include_imports except translates the imports to exports
• include_exports_imported - Like include_exports except translates the exports to imports

(suggestions for better syntax/naming welcome)

For example, include_imports would be useful when one wants to make a library component that can link to another component and otherwise occupy the same world. And include_imports_exported would be useful when one wants to make a world for the implementation that components of another world need.

In my current projects, I'm finding myself effectively working around the lack of include_imports by splitting out worlds that only have imports and than having the main worlds and library worlds include them. And for the lack of include_imports_exported I'm manually duplicating and translating imports in one world to exports in another.

[lukewagner]

This seems like a good idea; the imports worlds in various WASI proposals always felt a bit artificial and like something we ideally wouldn't need to define.

One slightly different take is that WIT could define imports(w) or exports(w) meta-functions that took an input world w as a parameter and returned a new world, so that you could write, e.g., include imports(wasi:http/proxy). Separately, I've thought about intersect(w1, w2) and union(w1, w2) meta-functions that could be useful, and framing these all as functions, rather than top-level statements, would allow them to be used together (e.g., union(imports(w1), imports(w2))).