Replace the if operator by an unless operator.

[ghost]

Split our from discussion in #652 as requested there.

For AngryBots with if expanded to block/break patterns and trivial if replaced by select:

Total blocks 169674 and single use block labels 139113 (82%)
Total block/br_if 125276 and single use block labels 110351 (88%)

There are a lot of block/br_if patterns (74% of all the blocks) and in 88% of these the label is used only once.

It would reduce the depth count within these blocks to optimize for this case and this might help compression a little.

It might also make a good sugar opcode to bundle this combination which accounts for 65% of all block instances, and that would lead to an (unless ...) == (block $l (br_if $l ) ...) operator in which the label is also restricted to a single use and thus the depth not even available in the body of this operator. At the same time it would return no values so be very useful in block top level expression positions.

The if_then_else pattern would then be (block $l (unless ... (br $l)) ...) and could return values, and breaks out of either branch would use the same $l label and the same depth as in the current if operator.

This would also address the inverted-condition issue with the current if operator, so now the condition would naturally translate into machine code using a compare-branch machine code. If the producer wants to express the when pattern then it would be responsible for inverting the condition.

What do people think?

[ghost]

Using block/br_if versus if/then/else or even an if/else operator seems to make little difference to the brotli compressed file size with the new post-order encoding. Just speculation but perhaps with the block expression count gone the block and br_if bytes match more copied sequences or the literal predictor is doing a much better job. Since this is now of marginal benefit, closing. Another option that could be considered with the post-order encoding is to allow the else opcode to stand alone to implement if/else.