Introduce arbitrary import/export depth

Among the things introduced are single-level imports/exports, how about, introducing arbitrary depth imports/exports? Any integer >= 1 that is.
For example, 3-level imports would be useful to maintain the 2-level depth, while using the ESM integration proposal.

(import "./mod.mjs" "Math" "random" (func $Math::random (result f64)))

Although, of course, I could re-write the host's code to use a single-level import in that case, but for multiple values that are already inside of an object, this becomes cumbersome.

[lukewagner]

That's a great point. The PR #26 already generalizes the alias syntax to support a sequence of N exports (link), so probably it makes sense to also allow N exports in import statements as well.

One question is whether we should have N-level imports show up as such in the binary/text format, or have them just be sugar for a single-level import of nested instances + alises. I would think the latter, treating the fixed-2-level-import form as "legacy".

[lukewagner]

With #35 merged and Module Linking as a new layer embedding core wasm, there are no longer two-level imports in the AST, text or binary format. We could consider re-adding them to the text format as syntactic sugar, in which case the generalization to N-level makes sense, but I wonder, without the requirement of backwards compatibility: is it worth the complexity?

@alexcrichton @rossberg thoughts?

[fitzgen]

In my experience implementing support for the earlier proposal in Wizer, significant complexity was involved in synthesizing instances / instance types from sequences of 2-level imports. I'd prefer that either we don't add 2-level imports back, or we don't make them implicitly define instances / instance types.

[alexcrichton]

I would personally go for the more conservative route and require single-level imports now that and adapter module is different from a core module. I'd figure we could add sugar/extras in the future if necessary.

[rossberg]

Staying conservative for now makes sense to me. The desugaring of multi-level imports is complex and has many nasty corner cases when there are overlaps.

[lukewagner]

Ok, thanks all for the feedback. I'll close this issue for now and we can reopen or file a new issue in the future if we want to reconsider.