Don’t inline sub(){ 0; return $x }

If return occurs at the end of a sub, it is optimised out of the
execution, chain, so we have to look at the op tree structure to
detect it.
const-optree.t: Correct comment
Handle multiple closures in sub(){$x} const-izing

Till now, we were checking the reference count of the variable that we
have just closed over, to see whether the newly-cloned sub can become
a constant.  A reference count of 2 would indicate that only the outer
pad and the pad of the newly-cloned sub held references.

Recent commits also checked whether the variable is used in lvalue
context in the outer sub in places other than its declaration.

This is insufficient to detect cases like:

    my $x = 43;
    my $const_closure = sub () { $x };
    my $other_closure = sub {$x++};

Although it does work if the $other_closure comes first (because it
holds a refcount by the time the $const_closure is created).

Extending the check for lvalue uses to inner subs as well (the changes
this commit makes to op_lvalue_flags) fixes that issue.  It does not
allows cases like

    my $x = 43;
    my $other_closure = sub { $x };
    my $const_closure = sub () { $x };

to create a constant, because the reference count check still prevents
it.  I tried removing the reference count check, but it fails for
cases like \(my $x = 1), which allows $x to be referenced elsewhere,
even though the only lvalue use of it is its declaration.

As with the commits leading up to this, we allow a simple sub(){$x} to
create constants erroneously where it would have done so before, but
with a deprecation warning.

The deprecation warning had to be moved, because it could trigger even
in those cases where the refcount check fails and we don’t create a
constant, which is just wrong.

This commit does not account for string eval within the scope of
the variable.
op.c:Start the search for const vars at CvSTART

When we search an op tree to see whether it could become a constant
closure, we search the op execution chain, but we don’t necessarily
start at the beginning.  We start at the outermost op of the first
statement’s contents.  That means that for sub {$a+$b} we begin the
search at the + (add), even though the full execution chain is next-
state, gvsv, gvsv, add, leavesub.

It was this oddity that led to bug #63540.  Originally (before
beab0874143b), the search through the op chain started at CvSTART
(the start of the execution chain), but was accidentally changed
in beab0874143b.  (That was also when sub(){return 2} stopped
being inlined.)

Changing this back to the way it used to be allows use to remove the
check to see whether a null op has kids, which was added to handle op
trees like

 b leavesub
 -   lineseq
 1     nextstate
 -     null ->9
 3       and
 2         padsv
 8         leave
 4           enter
 5           nextstate
 7           die
 6             pushmark
 9     nextstate
 a     const

which is the result of sub { if($x){ die }; 0 }.

If we begin the search at the null op, and if nulls are skipped, we end up missing the entire ‘if’ block and seeing just null, nextstate, const, leavesub, which looks constant.
Remove SvREADONLY_on from op.c:op_const_sv

If we turn on the padtmp flag, then this this SV will never be seen in
lvalue context, so whether it is read-only is irrelevant.  Don’t even
bother making it so.
First arg to op_const_sv is never null
Allow sub():method{CONSTANT} to be inlined

This brings non-closure subs into conformity with closures.