Make the composite opcodes easier to parse using a generic S-expression parser

[AndrewScheidecker]

The composite opcodes pack a lot of information into a single S-expression "atom", e.g. i32.load_s/i8/4. My WAST parsing is structured as a generic S-expression parser followed by a transformation defined on S-expressions. The problem is that an opcode like i32.load_s/i8/4 comes in as a single atom, so the WAST-specific transform needs to be able to recognize all the variations. With something like i32.add it's practical to just enumerate the possibilities, but something like i32.load_s/i8/4 really needs WAST-specific lexing at some point in the pipeline.

If these opcodes were split into multiple atoms, e.g. i32.load_s i8 alignment 4, it would be much easier to use a generic S-expression parser.

[kg]

Yeah, I think type information should be operands to the opcode. I don't like cramming a bunch of data into the opcode with delimiters.

[sunfishcode]

This is now fixed in the spec repo, with the offset= and align= syntax.