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:>,<,% ->-
[MERGE] add PADRANGE op and $B::overlay

This commit implements three optimisations and one new feature.

The new feature is $B::overlay, which can be set to a hash ref, indexed by
op address, that allows you to override the values returned by the various
B::*OP methods for a particular op. This specifically allows Deparse to be
tricked into seeing a pre-optimisation view of the optree, and so makes
adding new optimisations (like the one in this commit) a lot easier.

As regards optimisations: first, a new save type is added:
SAVEt_CLEARPADRANGE, which is like SAVEt_CLEARSV but specifies a range of
targs to be cleared. The save type, target base and range all fit within a
single integer pushed on the save stack.

Second, a pushmark followed by one or more pad[ahs]v ops (and possibly
some mixed-in null, list and nextstate ops) will sometimes be replaced by
a single padrange op. Like other pad ops, this specifies a targ, but in
addition the bottom 7 bits of op_private indicate a target range.
pp_padrange has two main actions: with OPpLVAL_INTRO, it pushes a
SAVEt_CLEARPADRANGE onto the save stack and turns off SvPADSTALE on all
the lexicals; and in non-void context, it pushes all the lexicals onto the
stack.

Third, for the specific case of the construct my(...) = @_, the
ops to push @_ onto the stack (pushmark/gv[*_]/rv2sv) are skipped,
and the OPf_SPECIAL flag on the padrange op is set: this tells
pp_padrange to push @_ directly.

Note that not sequences of pad ops are consolidated into a single
padrange op; the chief constraints are that:

* they must form a list (i.e. start with pushmark);
* the targs must form a contiguous range;
* the flags of the ops must all be similar; e.g. all INTRO or all not,
   all void or all not, etc;
* only a subset of flags are allowed; e.g. we don't optimise with
  OPpPAD_STATE or OPpMAYBE_LVSUB present.

For the specific case of void/INTRO, we consolidate across nextstate
boundaries (keeping only the last nextstate); i.e.

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

becomes a single padrange op. Note that the padrange optimisation is
particularly efficient for the void/INTRO combination: formerly,
my($a,$b,@c,%d); would be compiled as

    pushmark; padsv[$a]; padsv[$b]; padav[@c]; padhv[%d]; list; nextstate

which would have the effect of pushing $a, $b onto the stack, then
pushing the (non-existent) elements of @c, then pushing the %d HV; then
pp_list would pop all the elements except the last, %h; finally, nextstate
would pop %h.  Instead, padrange skips all the pushing and popping in void
context.  Note that this means that there is one user-visible change caused
by this optimisation:

    f();
    my @a;
    sub f { tie @a, ...; push @a, .... }

Here, @a is tied and already has elements by the time the 'my @a' is
executed; formerly, FETCH would be called repeatedly to push the elements
of @a onto the stack, then they would all be popped again at the end of the
'my @a' statement; now FETCH is never called.

The optimisation itself is implemented by converting the initial pushmark
op into a padrange, and updating its op_next. The skipped ops are *not*
cleared; this makes it easier for S_find_uninit_var() and Deparse.pm to do
their stuff. Deparse is implemented by using the new $B::overlay facility
to make the padrange op look like a pushmark op again; the rest of the
Deparse code just sees the original unoptimised optree and so doesn't
require any knowledge of the padrange op.