bpo-46841: Improve the failure stats for COMPARE_OP

[brandtbucher]

With the move to inline caching, jumps are getting a bit longer. This adds new category of COMPARE_OP failures for the (increasingly more common) case where a COMPARE_OP instruction is followed by an EXTENDED_ARG.

New stats for a full pyperformance run:

Kind	Count	Ratio
unquickened	7348739	0.4%
specialization.deferred	359371048	21.7%
specialization.deopt	15730	0.0%
hit	1289210975	77.8%
miss	943057	0.1%

Specialization attempts

	Count	Ratio
Success	289083	4.8%
Failure	5723386	95.2%

Failure kind	Count	Ratio
extended arg	2473174	43.2%
not followed by cond jump	1258612	22.0%
float long	671682	11.7%
set	579241	10.1%
different types	165539	2.9%
bool	137038	2.4%
tuple	119632	2.1%
other	115566	2.0%
big int	95547	1.7%
bytes	46481	0.8%
baseobject	37335	0.7%
list	22634	0.4%
string	704	0.0%
long float	201	0.0%

https://bugs.python.org/issue46841

[sweeneyde]

Looks good.

We could also consider packing extended opargs into the top 13 bits of cache->mask when it fits there.

Edit: I suppose it would be difficult to do next_instr++ the correct number of times in ceval. Store how far to jump ahead for that branch as well?

[brandtbucher]

@markshannon is already brainstorming ideas for how to tackle the general problem of longer jumps in faster-cpython/ideas#297 and faster-cpython/ideas#301. We should probably wait to see how that pans out first before adding a bunch of new logic to the different COMPARE_OP specializations.

[markshannon]

Feel free to add suggestions to faster-cpython/ideas#301.

faster-cpython/ideas#297 is more about giving the bytecode compiler freedom to lay out basic blocks.