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

[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!