Extends Name Section w/ Type & Field

[ashleynh]

This PR updates the spec to add additional subsections for type and field within the custom name section. struct.get and struct.set also updated to indicate that their field indices are of type fieldidx, instead of u32. As a result, the metavariable representation was updated from i (integers) to y (indices).

Closes #193

[tlively]

LGTM. Would like a review from @rossberg as well.

[rossberg]

Note that field offsets are different in nature from other indices: in programming language terms they are numeric "labels" (in the record sense), whereas all other indices are numeric "variables". The difference is somewhat technical, though (has to do with how binding works and what can be renamed/shifted how), so I can live with calling them fieldidx.

[ashleynh]

Thanks for taking a look @rossberg! Can you expand on the technical differences w.r.t. binding and renames/shifts? Would calling it fieldOffsetIdx be preferred? We could add a note calling out the how they are numeric labels in the record sense.

[rossberg]

No worries, I think the name is fine. The technicalities aren't easily explained in a couple of sentences, but roughly, for variables, use site and definition site are connected by scoping, i.e., you'll look up a variable in the current scope chain. Labels on the other hand are tied to, and looked up in, the type of some operand. Multiple labels of the same name can be used in the same scope while referring to different definitions (or sometimes, do not even need a definition). When you get down to something like lambda calculus, one consequence is that variables are freely renameable (and substitutable), while labels are not. But I'm digressing, not sure this is helpful... :)

[ashleynh]

Very helpful explanation, thank you!