Stop recursion from losing lex fh names

sub r {
    r($_[0]-1) if $_[0];
    open my $fh, "/dev/null";
    print "$_[0] $$fh\n"
}
r(5);
__END__

Output:
0 *main::
1 *main::
2 *main::
3 *main::
4 *main::
5 *main::$fh

The largest number represents the outermost call.

The handle name was being allocated as a target (a scratch variable
used by various operators to return values).  Targets are not shared
between recursion levels.

This commit tells pad_alloc to treat it like a constant, so it
is shared.
Fix skip logic in pad_tidy and cv_clone

Commit 325e1816dc changed the logic for determining whether a pad
entry is to be treated like a constant; i.e., shared between recursion
levels and sub clones.

According the old logic, a pad entry must be shared if it is marked
READONLY or is a shared hash key scalar.  According to the new logic,
the entry must be shared if the pad name has a zero-length PV (i.e.,
&PL_sv_no).

Two pieces of code were still following the old logic.  Changing them
fixes this old bug:

my $close_over_me;
sub  {
    () = $close_over_me;
    open my $fh, "/dev/null";
    print "$$fh\n"
}->();
__END__

Output:
*main::

The name attached to the implicit rv2gv op in open() was not being
copied by sub clones.

The previous commit is also part of the fix.

In the tests, I tested the combination of sub cloning and recursion,
since it seemed like a good idea (and also as a result of copying and
pasting :-).

S_pmtrans was still relying on the old logic, so it gets changed, too.
Avoid double stringification in pp_complement

Commit 91bba347 made targets exempt from uninit warnings.  The com-
mit message only says it has something to do with fixing warnings on
bitwise ops.

Commit a1afd1046 worked around that by doing an extra stringifica-
tion before assigning to the target, to produce an uninit warning
on purpose.

As far as I can tell, the only purpose of 91bba347 was to avoid the
warning for ~undef.  (I haven’t actually tried building the commit
before that to confirm.)

In any case, the uninit warning has been long tested for and is now
expected behaviour.

Since I am about to remove the uninit warning exemption for targets,
stop relying on that.

This speed ups the code slightly, as we avoid a double string-
ification.
[perl #118693] Remove PADTMP exemption from uninit warnings

This fixes a problem with undefined values return from XSUBs not pro-
ducing such warnings.

The default typemap for XSUBs uses the target of the entersub call (in
the caller’s pad) to return the converted value, instead of having to
allocate a new SV for that.

So, for example, a function returning char* will cause that char* to
be assigned to the target via sv_setpv.  Then the target is returned.

As a special case, NULL return from a char*-returning function will
produce an undef return value.  This undef return value was not trig-
gering an uninitialized warning.

All targets are marked PADTMP, and anything marked PADTMP is exempt
from uninitialized warnings in some code paths, but not others.

This goes all the way back to 91bba347, which suppressed the warning
with only a hit at why (something to do with bitwise ops warning inap-
propriately).  I think it was to make ~undef exempt.  But a1afd104
stopped it from being exempt.

Only a few pieces of code were relying on this exemption, and it was
hiding bugs, too.  The last few commits have addressed those, so kiss
this exemption good-bye!

pp_reverse had a workaround to force an uninit warning (since
1e21d011c), so remove the workaround to avoid a double uninit warning.
Increase XS::Typemap::VERSION to 0.11