Clarify and regularize text format index parsing rules

[lukewagner]

This PR intends to resolve #648 by regularizing and more-clearly defining the text format rules for core- and component-level indices, identifiers and inline aliases. One nice thing with the changes in this PR is that there is now an explicit core-prefix(...) in the grammar at all the places where core might (when a plain $id is not used) get injected.

The test/syntax/indices.wast tries to test all the syntactic cases touched by this PR. The commented-out lines currently fail in wasm-tools and the rest pass as-is. This helps identify what the concrete delta from the status quo is. I didn't add any negative tests since I expect we'll need a phase-out process before rejecting anything that is accepted now.

PTAL @bvisness @alexcrichton

[bvisness]

I think this should be (core Xᵢ <idx>), as the Xᵢ will be un-prefixed (e.g. memory alone).

[lukewagner]

When a core:{X}idx is used inside a (core ...) block (e.g., (core instance (instantiate $M (with "" (instance (export "mem" (memory $i "mem"))))))), there is no core needed, so the approach used in this PR is that core:{X}idx rules always have no core prefix, and when you need one, the grammar has an explicit core-prefix(<core:{X}idx>).

[bvisness]

Is this too permissive? It seems to include e.g. (core module $foo), but the new rule for core:inlineexport is:

core:inlineexport   ::= (export <core:name> <core:externidx>)

That would seemingly imply that we could have a core module exporting a core module, which is not the case. I guess the problem is that core:sort includes not just things in core WebAssembly, but also core modules and core instances themselves.

[lukewagner]

So this is where the validation rules come in (in this and other cases) to winnow down what the grammar allows and throw out cases that aren't currently supported by core wasm (but hypothetically could in the future); I think this is mentioned below in the explainer.

[bvisness]

This seems unfortunate to me because it's no longer clear which kind of index is required here. I'm not sure if this is how it works today, but could it possibly take e.g. <core:instanceidx> instead of just <idx>? This would allow either a bare index or (core instance $foo).

Alternatively you could maybe just define a little notation for what kind of bare index is required, just for reader comprehension.

[lukewagner]

With the grammar rules as defined, a <core:instanceidx> would mean that you could use an inline alias inside an alias which seemed like maybe too inceptive. Ultimately, the grammar bottoms out at a <u32> or <id>, and validation rules say "it has to be an instance in the instance index space", so that seemed kinda good enough, given that the second <idx> also needs special validation rules?