rpeep(): OP_SORT with code block has OPf_SPECIAL

In rpeep(), we check whether the OP_SORT has a code block as the first arg
(e.g. sort {BLOCK} ...) by testing for OPf_STACKED, then looking for
an OP_SCOPE or ex-OP_LEAVE. However, ck_sort() has already checked for
this situation and set the OPf_SPECIAL flag. So just just check for this
flag in  rpeep(); leave in the OP_SCOPE/ex-OP_LEAVE checks as just
assertions.

Also, add some commentary to ck_sort() and S_simplify_sort().
OP_SORT: store start of block in null->op_next

When a sort with a code block, like sort { BLOCK } arg, ...
is compiled, it comes out like

     sort
        pushmark
        null
           scope
              BLOCK
        arg
        ...

(The 'scope' may be instead be 'ex-leave' depending on circumstances).

At run time, pp_sort() navigates its way down from the sort op to find the
start op of the BLOCK. We can shorten this process slightly by storing the
start of BLOCK in the otherwise unused op_next field of the OP_NULL.
Effectively we are using the null->op_next field as a surrogate op_other
field for the op_sort (which doesn't have a spare field we could store
the pointer in).

The main point of this commit however is not the slight speed up from
skipping a couple of pointer follows at run-time; rather that it will
shortly allow us to trim any null ops from the beginning of the BLOCK. We
can't do this directly, as that would involve changing the scope->op_first
pointer, which might confuse B:: type modules.
code following eval {} not always optimised

In something like this

    eval { 1 while 1 };
    $x = $a[0];

The optimising of the while loop makes Perl_rpeep() miss processing the
chain of ops from the OP_LEAVETRY onwards. So in the code above for
example, the alem wont be optimised into an alemfast.

Fix this by explicitly recursing into the entertry->op_other branch
(which actually points at the leavetry).

The infinite loop above can be broken by, for example, a signal handler
calling die.
rpeep(): remove trailing OP_NULLs etc

Perl_rpeep() elides OP_NULLs etc in the middle of an op_next chain, but
not at the start or end. Doing it at the start is hard (and not addressed
here); doing it at the end is trivial, and it just looks like a mistake in
the original code (there since 1994) that was (incorrectly) worried about
following through a null pointer.
rpeep(): elide just-nulled ops

Perl_rpeep() currently spots "empty" ops like OP_NULL, OP_SCOPE
and elides them from the op_next chain (by setting oldop->op_next to point
to the op following the current op). However, if rpeep() itself
op_null()'s the current op, then when the main loop is re-entered, that
mechanism is bypassed. Modify re-entry to the loop in this case so that
the just nulled op re-processed and thus elided.

(Also document what the OP_SASSIGN/OP_SUBSTR optimisation is doing;
studying that was what originally led me to this general fix.)
elide "empty" ops at the head of op_next chains

Currently all OP_NULL/OP_SCOPE/OP_SCALAR/OP_LINESEQ ops (which all map at
run time to pp_null()) are eliminated from op_next chains *except* ones at
the head of a chain (e.g. pointed to by o->op_other).

The API of peep()/rpeep() makes it difficult to directly do this within
the function itself, as it has no return value  - and thus
RPEEP(o->op_other) has no way to update op_other to skip the first op if
it happens to be a null or whatever.

Instead, we add a small helper function, S_prune_chain_head(), and
always call it after we call peep, e.g.

         CALL_PEEP(PL_main_start);
         finalize_optree(PL_main_root);
        +S_prune_chain_head(aTHX_ &PL_main_start);

rpeep() is also complicated by its recursion reduction mechanism, where
it saves the addresses of several ops before recursing on them. I had to
change this so that it saves the addresses of the addresses of the ops
instead, so they can be updated: i.e. rather than saving o->op_other,
it saves &(o->op_other).

With this commit, nothing in the test suite triggers executing pp_null(),
execpt OP_REGCMAYBE and S_fold_constants(). I verified this with the
following hacky diff:

>>>>diff --git a/op.c b/op.c
>>>>index 716c684..819a717 100644
>>>>--- a/op.c
>>>>+++ b/op.c
>>>>@@ -3489,6 +3489,7 @@ S_op_integerize(pTHX_ OP *o)
>>>>     return o;
>>>> }
>>>>
>>>>+int XXX_folding = 0;
>>>> static OP *
>>>> S_fold_constants(pTHX_ OP *o)
>>>> {
>>>>@@ -3504,6 +3505,7 @@ S_fold_constants(pTHX_ OP *o)
>>>>     SV * const olddiehook  = PL_diehook;
>>>>     COP not_compiling;
>>>>     dJMPENV;
>>>>+    int XXX_folding_old = XXX_folding;
>>>>
>>>>     PERL_ARGS_ASSERT_FOLD_CONSTANTS;
>>>>
>>>>@@ -3583,11 +3585,13 @@ S_fold_constants(pTHX_ OP *o)
>>>>     assert(IN_PERL_RUNTIME);
>>>>     PL_warnhook = PERL_WARNHOOK_FATAL;
>>>>     PL_diehook  = NULL;
>>>>+    XXX_folding = 1;
>>>>     JMPENV_PUSH(ret);
>>>>
>>>>     switch (ret) {
>>>>     case 0:
>>>> 	CALLRUNOPS(aTHX);
>>>>+        XXX_folding = XXX_folding_old;
>>>> 	sv = *(PL_stack_sp--);
>>>> 	if (o->op_targ && sv == PAD_SV(o->op_targ)) {	/* grab pad temp? */
>>>> #ifdef PERL_MAD
>>>>@@ -3608,10 +3612,12 @@ S_fold_constants(pTHX_ OP *o)
>>>>     case 3:
>>>> 	/* Something tried to die.  Abandon constant folding.  */
>>>> 	/* Pretend the error never happened.  */
>>>>+        XXX_folding = XXX_folding_old;
>>>> 	CLEAR_ERRSV();
>>>> 	o->op_next = old_next;
>>>> 	break;
>>>>     default:
>>>>+        XXX_folding = XXX_folding_old;
>>>> 	JMPENV_POP;
>>>> 	/* Don't expect 1 (setjmp failed) or 2 (something called my_exit)  */
>>>> 	PL_warnhook = oldwarnhook;
>>>>diff --git a/pp_hot.c b/pp_hot.c
>>>>index 36eac2b..ccb582f 100644
>>>>--- a/pp_hot.c
>>>>+++ b/pp_hot.c
>>>>@@ -68,9 +68,16 @@ PP(pp_gvsv)
>>>>     RETURN;
>>>> }
>>>>
>>>>+extern int XXX_folding;
>>>> PP(pp_null)
>>>> {
>>>>     dVAR;
>>>>+    if (!XXX_folding && PL_op->op_type != OP_REGCMAYBE) {
>>>>+        sv_dump((SV*)find_runcv(0));
>>>>+        op_dump(PL_op);
>>>>+        op_dump((OP*)PL_curcop);
>>>>+        assert(0);
>>>>+    }
>>>>     return NORMAL;
>>>> }
>>>>
[MERGE] avoid calling pp_null().

Several 'empty' ops like OP_NULL and OP_SCOPE call pp_null() at run-time
(which just returns). Attempts are made to strip such empty ops from the
op_next execution chain, but this has not been not complete. In
particular, ops at the head or tail of a sub-chain, or ops that rpeep()
has itself nulled, weren't being eliminated.

This merge avoids all calls to pp_null() in the test suite, apart from
those called via the constant folder (which is called before null op
elimination), and OP_REGCMAYBE (which isn't addressed here).