Re-thinking loops.

[ghost]

The current semantics for loops is:
"Branches that target a loop do not yield a value; they pop any values pushed onto the stack since the start of the loop and set the program counter to the start of the loop."

It also appears that a loop exit, the fall-through path, can leave zero or one values on the values stack as defined by the signature result values? This might scale in future to more values, but the common case would be to want to unwind excess values, and it is not possible to use a branch to exit and unwind the values stack because there is no break target for loops now. The loop could be wrapped in a block to exit the loop with a branch to unwind, but if this is the common case in future then perhaps the loop exit should be simplified to just to unwind and return no values, or the break label put back to give it the flexibility that is really needed for all the paths of a loop.

Based on some experimentation with a functional SSA style encoding for wasm suggests that the current semantics for backward branches to the loop header and the loop entry might be usefully extended to use the signature arguments. What was required for a functional SSA style was for the loop to have a set of argument variables that receive values from both: 1. an initial set of values which could be popped from the values stack on entry to the loop; 2. backward branches which pop the required number of values from the values stack (as specified in the loop signature arguments) and the rest unwound. This might be similar semantics to blocks using the signature arguments to specify values popped from the values stack on entry.