Interleaved "header" sections and the text format

[alexcrichton]

I figured it was good to make a dedicated issue for this given the discussion happening on a few other places at this point as well. In the module linking proposal the initial sections (type, module, instance, and alias), can all appear interleaved. This issue is intended to ask the question "how do we represent this in the text format?" Some current known things are:

• Alluded to in Intermingled import/type sections and elaboration to single-level instance imports #17 and here the current text format allows for definitions such as:

(import "" "" (func (type $t)))
(type $t (func))

so should this keep working?

• There should probably be a mechanism for @custom and repeated sections annotations#11 where custom sections may need to be explicitly placed after a particular header section.

• Ideally the text format is "round-trip-able" where given any sequence of sections in a binary module when printed there's a way you can convert that text back to binary and produce the same module.

This seemed independent enough from other issues that it might be good to have a singular place to discuss here! One possible option I'd propose is new grouping constructs like (aliases ...), (types ...), (imports ...), etc. Internally they would only allow the corresponding field to be declared and they would be serialize as-is with the group. Top-level singular items would then be sorted in a predefined order (e.g. types, imports, modules, instances, aliases) and would just simply be an error in validation if they referenced one another. This is not a great solution, though, and I hope a better idea is found.

[lukewagner]

As of #35, I think this question is answered with: we don't need to backwards-compatibly support forward references in the text format of adapter modules, so only backwards references are allowed. In general, with adapter modules, I think the processing model is to linearly walk, definition-by-definition, through the adapter module definitions and maintain a type environment (sortof like we do when validating instructions in core function bodies).

I'll tentatively close this issue, but if there are still open questions, please feel free to reopen.