tweak PERL_TRACE_OPS for usability

Currently with -DPERL_TRACE_OPS builds, a table of OP dispatches per
optype is always printed in perl_destruct().  Since this also affects
miniperl, it makes both make & make test exceedingly noisy, and might
interfere with passing make test (I never waited til completion).

Although such builds arent meant for production, we can still make
them more casually usable; gate the printing with PL_debug to make it
quiet by default (-Dq -Dv -D0 options will all enable it).  Also dont
print 0 values, which dramatically reduces output for simple one-liner
scripts.

Also add PERL_TRACE_OPS_EXT and PL_op_histo[] to create a 2nd set of
experimental/scratchpad counters (default size 12), and print only
non-0 values like above.  Use separate array to avoid error-prone
bounds testing.  But preserve the extra OP_max+1 slot originally
provided by 75d476e24a, in case porters are currently using it
privately.

Define 2 macros; PERL_TRACE_OPS_INC, PERL_TRACE_OPS_HIT, to hide the
(re)implement following exec-counts:

 - count op-execs per optype (reimplemented)
 - count total ops executed
 - count odd/even op_types
 - count OPs with op_spare set

NOTE: its expected that porters will not try doing
PERL_TRACE_OPS_HIT(PERL_TRACE_OPS_EXT) in their code.
runops_debug: tweak PERL_TRACE_OPS_* users

add use of PERL_TRACE_OPS_HIT() on OP's "patched" status, ie whether
(PL_op->op_ppaddr != PL_ppaddr[PL_op->op_type]).  Note: this needs the
dVAR added in the previous patch.

drop use of PERL_TRACE_OPS_INC(PL_op->op_type), to reduce output and
thus focus on the derived properties such as "patched" status.
This yields test results like the following:

$ ./perl -Ilib -Dq ./ext/arybase/t/splice.t
1..23
ok 1
...
ok 23
Trace of all OPs executed:
  extra.0: 114745
  extra.1: 42966
  extra.2: 71779
  extra.3: 114745
  extra.5: 114732
  extra.6: 13

extra.6 are hits on the "patched" detector, it suggests that patched
ops are quite rare, and optimization might be indicated.
op.c: regularize OP_AELEMFAST_LEX vs OP_AELEMFAST setup.

commit 10884df96723d4 promoted CHANGE_TYPE as the "normal" way to
initialize op_type and op_ppaddr fields.  This suggests that
Perl_rpeep()s tweaking of OP_AELEMFAST and OP_AELEMFAST_LEX is
something of a special case.

It turns out that these are pretty normal too; since regen/opcode.pl
insures that PL_ppaddr[OP_AELEMFAST_LEX] == PL_ppaddr[OP_AELEMFAST],
the invariant: o->op_ppaddr == PL_ppaddr[o->op_type] holds after both
the OP_AELEMFAST and OP_AELEMFAST_LEX branches, and the stronger
semantics of CHANGE_TYPE() can be used to communicate this normality.

On a gcc x86-64 -DEBUGGING build, this enlarges 'size op.o' by 16
bytes, but before and after 'objdump -DS op.o' output suggests that
the code itself is identical.
op.c: CHANGE_TYPE for op_integerize and ck_spair

These 2 users do the ++o->op_type trick to modify the OP to its
optimized doppelganger.  But CHANGE_TYPE()s postcondition holds:
o->op_ppaddr = PL_ppaddr[o->op_type], so using it conveys this.
Also fix CHANGE_TYPE(o, ++type) expansion problem with an autovar
inside the "braces".
start obsoleting op_ppaddr

op_ppaddr is basically a cached copy of PL_ppaddr[] dispatch entries;
while it can be patched, it is rarely different than the global table.
Start obsoleting the pointer:

- add %pp_patched ptr-table to interpreter.
- when LINKLIST detects a "patched" op
    populate $pp_patched{op}
    set op_spare (steal now, rename op_patched someday)
- in runloops,
    check op_spare, fetch $pp_patched{op}

op.c: set op_spare/op_cust in LINKLIST

In Perl_linklist, when (o->op_ppaddr != PL_ppaddr[o->op_type]), set
op_spare/op_cust bit, and increment last DPERL_TRACE_OPS_PAD slot
(extra.9 below).  This counts the OPs that have been modified by the
time theyre LINKED.

This appears to work - it finds same count of modified ops as 2
execution time tests previously added to Perl_runops_debug(): op-spare
bit set (extra.2,3), and the postcondition above (extra.4,5).

 $ ./perl -Ilib -D0 ext/arybase/t/splice.t
  extra.0: 40430
  extra.1: 68126
  extra.2: 108543
  extra.3: 13
  extra.4: 108543
  extra.5: 13
  extra.9: 13

TBD: extra.9 == extra.5 probably requires no loops over modified OPs.

dump.c: runloop debug (skip this)

add DEBUG_U print when o->op_ppaddr != PL_ppaddr[o->op_type]

This is the case for mapstart, which is why dispatching
(*PL_ppaddr[o->op_type])(aTHX) directly would result in a
"panic:..unimplemented_op.." message.

When mismatch is seen, we do a cheesy search for another OP_TYPE with
that op_ppaddr.  This found MAPSTART using GREPSTART, but for truly
custom pp-functions it counts down to -1, and displays a sentinel
op-desc.  Its useful for next patch, further extended patch after it.

dump.c: dispatch pp-code from PL_ppaddr[] directly (skip this)

Dispatch most OPs using (*PL_ppaddr[PL_op->op_type])(aTHX) directly.

DO NOT APPLY

It would be nice if op_ppaddr was an optimization detail, not a
requirement to allow patching in new behavior.  Then we could test to
see what gains the op_ppaddr pointer confers upon execution.  Fully
eliminating op_ppaddr is hard, (and we're likely to just confirm the
pointer is good, even considering its cost), so we cheat here.

This patch does indirect dispatch for most optypes, ie:
  PL_op = (*PL_ppaddr[PL_op->op_type])(aTHX);
but some ops are "bad", and dispatched directly, ie:
  PL_op = PL_op->op_ppaddr(aTHX);

The "bad" ones are those OPs whose type is "modified"
(o->op_ppaddr != PL_ppaddr[o->op_type]), so we
blacklist OPs which panic the indirect way.

This is fundamentally broken; as b82b06b "Reimplement $[ as a module"
shows, practically all OP_s can be modified, we just blacklist those
that currently are modified by one or more tests.

But for research purposes, it does help us determine (eventually) the
slowdown of direct PL_ppaddr[optype], as follows:

- run time make test (etc, etc, etc) on blead vs this branch,
  if no measurable differences then stop, reexamine tests, etc.

- with -DPERL_TRACE_OPS, ++PL_op_exec_cnt[PL_op->op_type] will profile
  the ops run during a test.  From that, we can compute that say 95%
  of X-million OP_s deref'd PL_ppaddr[], causing any measured slowdown.

TODO:

develop a good benchmarking scenario. (ya, just like that ;-)
- need make test under perf
- perlbench - real runtimes, less overhead than core tests.

build a branch with extra op_junk pointer in OP, benchmark it to get
costs (cache, footprint) of extra pointer, and infer from that
(caveats apply) the savings by eliminating op_ppaddr.

collect and analyse a lot of data.

BLUE-SKY:

Actually eliminating op_ppaddr is possible:
- define op_custpp flag in OP
  setOpAddr, setOpType manage the flag
- setOpAddr inserts "modified" ppaddrs into PL_custom_ops (or similar)
- runops loop checks op_custpp flag, query PL_custom_ops for dispatch.
  probly expensive, so want low population of them.

dvar for added check
run-likely
hoist CHANGE_TYPE to op.h from op.c

hoist so its available to perl.c and others, add braces for robustness.
define OP_IS_UNPATCHED
macro-in-dump
macro-in-op.c
opc-debug
opc-clean
enlarge to fit 10th item
missing patched might be causing extra failures, lessee
reset spare in CHANGE_TYPE, for op reuse
DEBUG_ breaks in linklist