op.c: Further simplify ck_sort

This code currently chases op_next pointers in the sort block to make
sure there is none that can point outside.  To avoid getting stuck in
loops, it has to check for those explicitly.

Instead of nulling out any op_next pointer that points to the leave
op, we can simply turn the leave into a null op (which we already do)
and have the leave op’s op_next pointer point to nothing.

That produces the same result in the end:  Execution of the sort block
is prevented from running rampant and escaping out of it, but exits
the runloop instead, returning control to pp_sort.
Simplify ck_grep

Back in perl 5.000, ck_grep would call ck_sort (which was still the
case until 354dd559d99 just recently) and the latter would traverse
its way through the op_next pointers to find an op that tried to
escape the block, setting its op_next pointer to null.  Then ck_grep
would traverse op_next pointers itself to find the place where ck_sort
stopped.  That caused problems for grep which were fixed in 748a93069b
(perl 5.001).  It was fixed by setting op_next to 0 on the first op,
so that the loop in ck_grep would not do anything.  But that loop was
left there.  This commit removes it.

There are also a couple of things I missed when disentangling
ck_grep and ck_sort in commit /354dd559d9.  I accidentally put
if (o->op_flags & OPf_STACKED) inside if (o->op_flags & OPf_STACKED).
And the OPf_SPECIAL flag was only being set for sort’s use, so ck_grep
doesn’t need to copy that.
pp_hot.c: Mention that pp_grepstart calls pp_pushmark
op.c: ck_grep does not need to check num of args

It calls ck_fun first, which does the same check, so it is
unnecessary.
op.c:ck_grep: Remove unnecessary op_next assignments

ck_grep is a tangled mess and I am trying to simplify it, but at each
step it is not at all obvious what is happening.

grep/map with a block starts out like this:

    grepstart
      pushmark
      null
        scope/leave
          block contents...
      arg1
      arg2
      ...

The if (o->op_flags & OPf_STACKED) at the top of ck_grep runs for
blocks.  The firstkid var refers to the null above, and gets its
op_next set (this code was in ck_sort until recently [ck_grep used to
call ck_sort], and this particular op_next assignment was specific to
grep and map).

Later, the thing is fed through ck_fun, whose OA_CVREF case transforms
the tree into this:

    grepstart
      pushmark
      null             ← new op
        null           ← original null
          scope/leave
            block contents...
      arg1
      arg2
      ...

Then cUNOPx(cLISTOP->op_first->op_sibling)->op_first gets its op_next
set.  By that point, that expression refers to the original null op,
so setting its op_next pointer to begin with seems pointless.

But it is not actually pointless.  Removing that statement breaks
things.  It turns out, as usual, that everything is more complicated
than it seems.  Setting kid->op_next = (OP*)gwop in the block-specific
if statement after setting the first null op’s op_next pointer results
in op_next pointers like this (the newly-created grepwhile doesn’t
link to the grepstart yet at this point):

  [grepwhile]
    grepstart
      pushmark
      null              -> block contents
        scope/leave     -> grepwhile
          block contents...
      arg1
      arg2
      ...

So ck_fun’s OA_CVREF handling, when it calls LINKLIST, sees that the
original null op already has its op_next set and does nothing.  With-
out it set, it copies it from the first kid, resulting in this (when
LINKLIST copies the op_next pointer out, it makes the kid it was cop-
ied from point to its sibling or its parent):

  [grepwhile]
    grepstart
      pushmark
      null
        null              -> grepwhile
          scope/leave     -> null (prev line)
            block contents...
      arg1
      arg2
      ...

That nonsensical arrangement of op_next pointers basically prevents
the block from running, because the grepwhile’s other pointer, copied
from the first null’s kid, ends up pointing to the grepwhile itself.

If we also remove the kid->op_next = (OP*)gwop assignment from the
if(OPf_STACKED) block, then we end up with this after ck_fun:

  [grepwhile]
    grepstart
      pushmark
      null
        null              -> first op in block
          scope/leave     -> null (prev line)
            block contents...
      arg1
      arg2
      ...

Then the op_next poiner from the first null’s kid is copied to
grepwhile’s op_other pointer, and everything works.

This also means we can remove the now-redundant LINKLIST call from the
if(OPfSTACKED) block, since ck_fun’s OA_CVREF handling also does that.
So now every vestige of the original call to ck_sort is gone.

This also means we no longer have to repeat NewOp(1101, gwop...).
op.c: ck_fun does not need to call LINKLIST

The branch in question is only reached when it is called from ck_grep,
which itself calls LINKLIST on exactly the same op.
op.c: ck_grep does not need to call listkids

It calls ck_fun, which applies list context to all the arguments,
since grepstart and mapstart have an L in regen/opcodes.