Roll back gratuitous changes to !instanceof code generation in the absence of pattern bindings

[srikanth-sankaran]

eclipse-platform/eclipse.platform.releng.aggregator#1875 brings to light a case of avoidable code generation change brought in by #2011 in particular by #2021

While the new code emitted is correct, it does result in large number of comparator errors - it can be impossible to study and verify/certify that all differences are kosher.

Also, the new sequence is less optimal and avoidably so. Here is a pertinent comment from org.eclipse.jdt.internal.compiler.ast.InstanceOfExpression.generateOptimizedBoolean(BlockScope, CodeStream, BranchLabel, BranchLabel, boolean) :

     /* A label valued to null is supposed to mean: by default we fall through the case ...
	   Both null means no "optimization" and we leave the value on the stack
	   But we have trouble when
	        this.pattern != null && trueLabel != null && falseLabel == null

	   In this case, since we have no control over placement of the trueLabel, we won't know where to emit the pattern binding code.
	   So what we do is always emit ifeq even when optimization would call for ifne and treat the whole "blob" of pattern matching
	   code as part of the predicate. if you think about long and hard you can convince yourself this is semantically correct.
	*/

While the comment explains why some optimizations have to sacrificed - that is only when pattern bindings are declared and we can restore original optimized sequence otherwise.