start reworking op_ppaddr

OPs op_ppaddr field has 2 purposes:
p1- a cached copy of PL_ppaddr[op->op_type]
p2- a patch-point to alter behavior, as used by b82b06b8 and Devel::Cover

Use of the OP-patching capability is exceedingly rare, its worth
examining whether we can do without it for a bit: 1st to uncover
crypto-dependencies, 2nd to evaluate the performance advantage of a
dedicated pointer-cache spread through the optree.

To test this, we need an unlikely-path lookup to implement p2.
So add a %patched_ops to interpreter, make Perl_linklist populate it
and mark op->op_patched (still op->op_spare for now) when
OP_IS_PATCHED(op) says so.  Runops_* finishes job by checking flag,
and retrieving the patched pointer.

Once its possible (WIP) to actually drop the op_ppaddr field (perhaps
-DPERL_NO_PPADDR), we can devise some experiments to tease out the
performance effects.

The patch does as follows:

- add %patched_ops to interpvar.  I used a ptr-table arbitrarily (HV
  <-> pointer nested-conversion-macro phobia), and probly bugs lurk in
  lack of cloning, but its a line-in-the-sand.

- in Perl_linklist, use OP_IS_PATCHED to mark OPs (o->op_spare = 1,
  rename op_patched later), and store op_ppaddr to %patchedpp.  This
  appears to catch all in-core cases, particularly b82b06b8.  dVAR is
  added to linklist because OP_IS_PATCHED needs it.

- in Perl_runops_*(), check o->op_spare, and fetch $patchpp{$op} when
  needed.  hopefully a bit-test is cheap enough as to be
  unmeasurable. Perl_runops_standard() needs added dVAR to access
  PL_ppaddr[] directly.

NOTES:

For this patchset, Ive adopted an "OP-patching" terminology purposely
to avoid confusion with CUSTOM ops and all their implementation
details.  This patchset disregards the possibility that an
op->op_patched flag could signal a single lookup in a unified hash for
OP_CUSTOM ops too, instead of using PL_custom_ops.  Note that
PL_custom_op_names, PL_custom_op_descs dont need to have identical
sets of keys, but rather some known super/subset relationship.

Devel::Cover is likely the highest profile and most sophisticated CPAN
user of OP-patching and op_ppaddr, its worth considering wrt viability
of this patchset.  DC has 2 OP-related techniques to apply:

- change PL_ppaddr[] entries to affect all OPs of that type (likely
  used for NEXTSTATE etc for accounting).
- change OP->op_ppaddr on per-OP basis.

These 2 techniques are available both before and after this patchset,
so modulo version branches, this is feasible in principle.  Managing
%patched_ops has extra overhead vs patching op_ppaddr, but toggling
op->op_spare and leaving 'disabled' entries is just as quick, and has
mnemonic value wrt disabled breakpoints.

TODO:

develop a benchmarking strategy. (ya, just like that ;-)
- need instrumentation to see cpu/cache effects.
- need to appreciate stochastics of any measurements.
- nice to leverage t/*, even if very suboptimal corpus for this purpose
- perlbench - real runtimes, less overhead than core tests.

Add a -DOP_JUNK #ifdef to add an extra op_junk pointer in OP,
benchmark it to get costs (cache, footprint) of extra pointer, and
infer from that what the savings due to eliminating op_ppaddr might be
(caveats apply).

collect and analyse a lot of data.

... focusing on single failure ...

 $ ./perl -Ilib t/run/fresh_perl.t
 1..92
 ok 1 - $a = ":="; @_ = split /($a)/o, "a:=b:=c"; print "@...
 not ok 2 - $cusp = ~0 ^ (~0 >> 1);
 # Failed test 2 - $cusp = ~0 ^ (~0 >> 1); at ./test.pl line 1019
 #      got "(tmp15993A:4)\top:i_modulo marked:0 but patched pp:53c620 gp:530a90\n(tmp15993A:4)\top:i_modulo marked:0 but patched pp:53c620 gp:530a90\n(tmp15993A:4)\top:i_modulo marked:0 but patched pp:53c620 gp:530a90\n7 0 0 8 !"
 # expected "7 0 0 8 !"
 # PROG:
 # $cusp = ~0 ^ (~0 >> 1);
 # use integer;
 # $, = " ";
 # print +($cusp - 1) % 8, $cusp % 8, -$cusp % 8, 8 | (($cusp + 1) % 8 + 7), "!\n";
 # STATUS: 0

the normal-dispatch branch detects a "patched" modulo operator,
probably resulting in the assertion failure I was looking for more
info on.

next reorder my CHANGE_TYPE in pp-i-modulo to back, see if I fucked up.
g++ is fussier about the casts in/out of ptr-table-store/fetch
reset op_spare in CHANGE_TYPE, for op reuse

reset flag whenever CHANGE_TYPE is used.  No proof that this fixes
anything (yet), so it seems prudent to both prevent and mention the
possible bug.
use LIKELY in runops_standard

HEAD~mumble added if/then on OP->op_spare (ie: op_patched) to choose
between fast and slow paths, with slow including %patched_ops lookup.
This should be a fine place to use LIKELY.  Do so separately to ease
examining the effects on the assembly and speed.

NOTE:
fast path does a direct dispatch
      op = (*PL_ppaddr[o->op_type])()

rather than the fastest
	op = op->op_ppaddr(aTHX))

The hope is that larger cache effects will overwhelm the extra indirection.
add -DUSE_PPADDR to run.c