br_if should pop its arguments.

A strong technical case for having br_if pop its arguments was made in WebAssembly/spec#330 yet it was merged anyway. It seems likely that the problems can be demonstrated and that this will need to be reverted. Here's a summary of the problems:

• The live range of the arguments is better known in general if they are popped, and explicitly duplicated only when necessary. With a pick operator it will be a common pattern to duplicate stack arguments only when necessary.
• With the arguments not popped, and still live after br_if, a single pass compiler would need to look ahead and hope unused values are dropped immediately, to know if this is their last use. It would be easier for a single pass compiler to defer get_local and pick argument leafs, not emitting them on the path-not-taken and avoiding register pressure on this path, than to have to look ahead to see if they are consumed by a drop. Also this strategy of deferring get_local and pick is needed for all the other operators that pop their arguments, is not a one off special case. The producer might not drop these values at all, or not immediately after the br_if, might not fit this pattern.
• If arguments are used out of stack order then they would need to be duplicated anyway. The originals are still on the stack, still live after br_if anyway, so keeping these duplicates live is not helpful.
• Even simple compilers should be able to optimize get_local leaf arguments. Values used more than once will in general be in local variables (without pick). So it should not prejudiced a simple compiler to just reload values from a local variable if used again after br_if, and this works in any order of use. With this pattern it is best to simply pop the arguments, to avoid having to drop them.
• Even if the arguments are used again after the br_if, if they are used out of stack order then they will need to be stored to local variables or reloaded from local variables or picked from the stack again. With this pattern it is also best to simply pop the arguments.
• The common code pattern is likely that the arguments are not used after br_if, or not in stack order, requiring a drop to clear them off the values stack. Some statistics will help here.
• Dropping the values is likely unnecessary for the producer after a br_if and producers will be conflicted between optimizing for encoding efficiency versus helping simple compilers by dropping dead values.
• Keeping the arguments duplicates live frustrates a familiar text decoder, which also has the burden of looking ahead to determine the live range of the arguments before it can decide if they can be emitted as an immediate expression. The alternative of binding the result argument copies to new scoped constants is verbose and frustrating for the reader.

[pizlonator]

It's too late for this.