Implement block signatures

[rossberg]

Implements WebAssembly/design#765; specifically:

• Adds block signatures (syntax: (block i32 ...) etc)
• Removes arities from branches
• Also simplifies if syntax: the label is on if now instead of the children, in order to be consistent with the signature
• Adjusts typing
• Adapts all tests (phew...)

[AndrewScheidecker]

What do you think about this for block signatures? (block (result i32) ...)
That provides a path for future support for block parameters or multiple results without changing the syntax for the typical case with no parameters and 0-1 results.

[rossberg]

@AndrewScheidecker, that's actually the syntax I started out with, but I backed out for 2 reasons:

• It violates the current convention that immediates should always be unparenthesised operands. In particular, this is desirable to fit the raw linear opcode syntax.
• Once I got into converting tests it proved to be so massive a nuisance that I really wanted the simpler syntax.

I think we can always allow the more general syntax later, and keep the simple one as a short hand.

[ghost]

I agree with @AndrewScheidecker on the syntax for the block signatures, and would just make the first immediate argument of the block operator a list of the result types, so even a block returning no values would have an immediate type e.g (block () (nop)) (block (i32) (i32.const 1)). But don't let that hold it up.

[sunfishcode]

The test changes lgtm. The proposed syntax seems acceptable to me.

I've updated the candidate 0xc wast file to use the syntax proposed here: https://github.com/WebAssembly/webassembly.github.io/pull/14 (though it's not hard to change if a different syntax is ultimately chosen).

[rossberg]

@JSStats, (block i32 i32 ...), which the parser already allows (but the validator rejects), is more in line with the rest of the syntax. Wasm avoids "headless" S-exprs (whose first item is not a keyword identifying the node) to keep the format understandable to generic S-expr parsers.

[ghost]

@rossberg-chromium Generic s-exp parsers have no constrain on 'headless' lists, it is very simple to parse the block list and access the second element to obtain the list of result types, more work to have to scan the list and pattern match. Perhaps the difference is between having a required element position for data versus an optional element named by it's first element. @AndrewScheidecker anticipated this using result as the first element, making it an optional element. There are already precedents in other areas of the s-exp format, such as function argument lists and result lists. But don't let that hold it up.