SpiderMonkey doesn't compute the correct completion value for some statements. For example `eval("1; while (false) ;");` should return undefined, but we're currently returning 1. See the following test262 tests for more examples: language/statements/do-while/cptn-abrupt-empty.js language/statements/do-while/cptn-normal.js language/statements/for-in/cptn-decl-abrupt-empty.js language/statements/for-in/cptn-decl-itr.js language/statements/for-in/cptn-decl-skip-itr.js language/statements/for-in/cptn-decl-zero-itr.js language/statements/for-in/cptn-expr-abrupt-empty.js language/statements/for-in/cptn-expr-itr.js language/statements/for-in/cptn-expr-skip-itr.js language/statements/for-in/cptn-expr-zero-itr.js language/statements/for/cptn-decl-expr-iter.js language/statements/for/cptn-decl-expr-no-iter.js language/statements/for/cptn-expr-expr-iter.js language/statements/for/cptn-expr-expr-no-iter.js language/statements/for/S12.6.3_A9.1.js language/statements/for/S12.6.3_A9.js language/statements/for-of/cptn-decl-abrupt-empty.js language/statements/for-of/cptn-decl-itr.js language/statements/for-of/cptn-decl-no-itr.js language/statements/for-of/cptn-expr-abrupt-empty.js language/statements/for-of/cptn-expr-itr.js language/statements/for-of/cptn-expr-no-itr.js language/statements/if/cptn-else-false-nrml.js language/statements/if/cptn-else-true-abrupt-empty.js language/statements/if/cptn-else-true-nrml.js language/statements/if/cptn-no-else-false.js language/statements/if/cptn-no-else-true-abrupt-empty.js language/statements/if/cptn-no-else-true-nrml.js language/statements/switch/cptn-a-abrupt-empty.js language/statements/switch/cptn-abrupt-empty.js language/statements/switch/cptn-b-abrupt-empty.js language/statements/switch/cptn-b-final.js language/statements/switch/cptn-dflt-abrupt-empty.js language/statements/switch/cptn-dflt-b-abrupt-empty.js language/statements/switch/cptn-dflt-b-final.js language/statements/switch/cptn-dflt-final.js language/statements/switch/cptn-no-dflt-match-abrupt-empty.js language/statements/switch/cptn-no-dflt-match-final.js language/statements/switch/cptn-no-dflt-no-match.js language/statements/try/cptn-finally-skip-catch.js language/statements/try/cptn-finally-wo-catch.js language/statements/try/cptn-try.js language/statements/while/cptn-abrupt-empty.js language/statements/while/cptn-iter.js language/statements/while/cptn-no-iter.js language/statements/with/cptn-abrupt-empty.js language/statements/with/cptn-nrml.js

Mass wontfix for bugs affecting firefox 52.

The relevant aspect of the ES spec is written in a "functional" style. That is, when you evaluate a Statement, the return value (which is a CompletionRecord) contains all the information, including the last-evaluated-ExpressionStatement value. This happens even if evaluation terminated abruptly due to a `break` or `continue` statement. There is a ton of logic strewn through a bunch of Evaluation algorithms explaining how these values get propagated and when one clobbers another. However, I think the functional style is window-dressing, and what the spec is trying to say is that there is a single "most recently produced value" slot per activation record, initially `undefined`; and every ExpressionStatement clobbers this slot, and in certain other places the slot gets set to `undefined` (like `if (false);` or the beginning of a `catch` block). If that's the case, I think this can be fixed without new bytecodes. We'll see.

(The proposed do-expression feature would require generalizing this, but I hope it can still be done with existing bytecodes.)