add $B::overlay feature

This allows you to alter the read-only "view" of an optree, by making
particular B::*OP methods on particular op nodes return customised values.
Intended to be used by B::Deparse to "undo" optimisations, thus making it
easier to add new optree optimisations without breaking Deparse.
pad_free(): don't clear SVs_PADSTALE

pad_free() clears the SVs_PADTMP bit. Since that bit is now shared
with SVs_PADSTALE, that gets cleared on state vars. It didn't matter up
till now, but the next commit will start optimising away pad ops, and
op_null() will call pad_free() which would clear the SVs_PADSTALE bit.

So only clear SVs_PADTMP/SVs_PADSTALE for non-lexical var ops.
add padrange op

This single op can, in some circumstances, replace the sequence of a
pushmark followed by one or more padsv/padav/padhv ops, and possibly
a trailing 'list' op, but only where the targs of the pad ops form
a continuous range.

This is generally more efficient, but is particularly so in the case
of void-context my declarations, such as:

    my ($a,@b);

Formerly this would be executed as the following set of ops:

    pushmark  pushes a new mark
    padsv[$a] pushes $a, does a SAVEt_CLEARSV
    padav[@b] pushes all the flattened elements (i.e. none) of @a,
              does a SAVEt_CLEARSV
    list      pops the mark, and pops all stack elements except the last
    nextstate pops the remaining stack element

It's now:

    padrange[$a..@b] does two SAVEt_CLEARSV's
    nextstate        nothing needing doing to the stack

Note that in the case above, this commit changes user-visible behaviour in
pathological cases; in particular, it has always been possible to modify a
lexical var *before* the my is executed, using goto or closure tricks.
So in principle someone could tie an array, then could notice that FETCH
is no longer being called, e.g.

    f();
    my ($s, @a); # this no longer triggers two FETCHES
    sub f {
	tie @a, ...;
	push @a, 1,2;
    }

But I think we can live with that.

Note also that having a padrange operator will allow us shortly to have
a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple
individual SAVEt_CLEARSV's.
add SAVEt_CLEARPADRANGE

Add a new save type that does the equivalent of multiple SAVEt_CLEARSV's
for a given target range. This makes the new padange op more efficient.
reindent block in leave_scope

The previous commit added a loop round a block of code; now increase
the indent of the body of the loop.
padrange: handle @_ directly

In a construct like
    my ($x,$y) = @_
the pushmark/padsv/padsv is already optimised into a single padrange
op. This commit makes the OPf_SPECIAL flag on the padrange op indicate
that in addition, @_ should be pushed onto the stack, skipping an
additional pushmark/gv[*_]/rv2sv combination.

So in total (including the earlier padrange work), the above construct
goes from being

    3  <0> pushmark s
    4  <$> gv(*_) s
    5  <1> rv2av[t3] lK/1
    6  <0> pushmark sRM*/128
    7  <0> padsv[$x:1,2] lRM*/LVINTRO
    8  <0> padsv[$y:1,2] lRM*/LVINTRO
    9  <2> aassign[t4] vKS

to

    3  <0> padrange[$x:1,2; $y:1,2] l*/LVINTRO,2 ->4
    4  <2> aassign[t4] vKS
Consolidate adjacent padrange ops

In something like

    my ($a,$b);
    my ($c,$d);

when converting $c,$d into a padrange op, check first whether we're
immediately preceded by a similar padrange (and nextstate) op,
and if so re-use the existing padrange op (by increasing the count).
Also, skip the first nextstate and only use the second nextstate.

So

    pushmark;
    padsv[$a]; padsv[$b]; list;
    nextstate 1;
    pushmark;
    padsv[$c]; padsv[$c]; list;
    nextstate 2;

becomes

    padrange[$a,$b]
    nextstate 1;
    pushmark;
    padsv[$c]; padsv[$c]; list;
    nextstate 2;

which then becomes

    padrange[$a,$b,$c,$d];
    nextstate 2;
Consolidate any single pad ops after a padrange

Given something like
    my ($a,$b); my $c; my $d;
then after having detected that we can create a padrange op for $a,$b,
extend it to include $c,$d too.

Together with the previous commit that consolidates adjacent padrange
ops, this means that any contiguous sequence of void 'my' declarations
that starts with a list (i.e. my ($x,..) rather than my $x) will
all be compressed into a single padrange op. For example

    my ($a,$b);
    my @c;
    my %d;
    my ($e,@f);

becomes the two ops

    padrange[$a;$b;@c;%d;$e;@f]
    nextstate

The restriction on the first 'my' being a list is that we only ever
convert pushmarks into padranges, to keep things manageable (both for
compiling and for Deparse). This simply means that

    my $x; my ($a,$b); my @c; my %d; my ($e,@f)

becomes

    padsv[$x]
    nextstate
    padrange[$a;$b;@c;%d;$e;@f]
    nextstate
fix optree_misc.t test after smoke

Some of the unicode setting in a smoke environment sets the open hints
output on nextstate lines.
ext/B/t/OptreeCheck.pm: fix hint stripping

The code that strips hints from a nextstate couldn't handle
the 'next' pointer being '-', e.g. v:>,<,% ->-