COMPARE_AND_JUMP instruction.

[markshannon]

In real CPUs there is a thing called macro-op fusion, where successive instructions are merged by the CPU.
Some pairs of instructions can be more efficiently executed as one.
The obvious example is test-jump pairs:

COMPARE_OP '<'
JUMP_IF_FALSE label

This is really a single operation:

COMPARE_AND_JUMP 'not <' label

To do this we need instructions that take two operands.
So let's allow that.
Instead of:

* 0 or more EXTENDED_ARGS
* Opcode/oparg pair
* 0 or more cache entries

We want some instructions to have this format:

* 0 or more EXTENDED_ARGS
* Opcode/oparg0 pair
* Oparg1
* 0 or more cache entries

This limits the second oparg to 16 bits. This shouldn't be a problem in practice, we can use the original two instructions if oparg1 >= 2**16.

Making a macro-op only makes sense if we want to specialize them differently from the component instructions and we do not generally specialize one or other of the component instructions.
COMPARE_AND_JUMP fits this description.

We already specialize COMPARE_OP to COMPARE_OP_INT_JUMP if we expect ints and the following instruction is a JUMP.
It would make the specialization more regular if we were specializing COMPARE_AND_JUMP and COMPARE differently.
Whether a jump is paired with a branch changes how we want to specialize it.

• We want to specialize COMPARE_OP by itself much like BINARY_OP.
• We want to specialize COMPARE_AND_JUMP as we already do for COMPARE_OP with int arguments.
• We want to specialize POP_JUMP_IF_FALSE by itself as something like TO_BOOL; POP_JUMP_IS_FALSE

See #297 for more discussion of jumps.

To avoid an explosion in instructions, it only makes sense to do this once all conditional jumps are forwards.