Normalize if/else blocks

[niloc132]

Fixes a longstanding TODO, and makes it easier for visitors to rewrite contents of blocks in if statements. Originally this change was intended to have no impact on generated JS, but resulted in a dangling-else problem, so changes were required to emit blocks when an if has an else.

Several tests needed to be updated to no longer assume that an unnecessary block was present after parsing.

Fix #10239

[niloc132]

As of this comment, samples are at 10807627 from 10821121, 13494 bytes saved, about 0.1% smaller.

I'm skeptical about making the new method on JBlock - though it should be used for for/while/do-while blocks as well (though not try blocks). Probably should resolve that one way or the other before merge.

The change to printing blocks in JS when an if has an else are more aggressive than they need to be - this need not happen unless the if has a child if, so we could optimize very slightly more here. Options here include keeping nested blocks for ifs manual and introducing a normalization pass rather than a feature of the JsToStringGenerator, or adding a visitor when printing the JS to see if the block is needed.

Java 17 change was done to ease test writing, and probably should be done anyway as part of the 2.14 release process.

#10240 was also addressed then reverted in this branch, to follow in a later PR.

[zbynek]

Suggested change

	if (jsStatement instanceof JsExprStmt && ((JsExprStmt) jsStatement).getExpression() instanceof JsFunction) {
	JsFunction jsFunction = (JsFunction) ((JsExprStmt) jsStatement).getExpression();
	if (jsStatement instanceof JsExprStmt exprStmt
	&& exprStmt.getExpression() instanceof JsFunction jsFunction) {

If we're using Java 17 here, we can simplify the casts a bit.

[niloc132]

Agreed - the change to 17 was mostly for tests, but it could benefit the code in other places too