sub.t: To-do test for recursive shared-hash-keys TARGs

This is only buggy under ithreads.

sub a {
  for (${\""}.${\""}) {
    $_ = $_[0] || __PACKAGE__;
    print "$_\n";
    a("road") unless $_[0];
    print "$_\n";
  }
}
a();

The outer call sets the scalar returned by ${\""}.${\""} to the cur-
rent package name.

The inner call sets it to "road".

Each call prints it twice, the outer call surrounding the inner call.
The output in 5.10-5.18 is:

main
road
road
road

because the inner call is clobbering the same scalar.  If __PACKAGE__
is changed to "main", it works, and prints

main
road
road
main

(as the script above also prints in 5.8.8).
ref.t: To-do test for retvals of folded ops
To-do tests for perl #78194

plus a regular (not to-do) test for an lvalue sub case that already
works properly.
Test that literal numbers and strings are read-only

including ${\3}, which currently fails under ithreads (and is hence a
to-do test).
Test !0 and !1 immutability and singletonness

The latter (for bug #114838) is a to-do test under ithreads.
Test (im)mutability of constants and constant-like subs

including many to-do tests
To-do test for #109746
Test readonliness of overload constants

including one to-do test
Change the tests for #3105 into to-dos

instead of testing for the incorrect behaviour
op.c:S_fold_constants: Add assertion

This code correctly handles a value returned by a folded constant that
is a target or a mortal.

If it is neither, then it takes ownership of a reference count (with-
out doing SvREFCNT_inc), so it ends up sharing a reference count with
whatever owned it before.  That is only safe to do with immortals,
which is (afaict) the only other type of scalar that can get through
this code, so it is actually correct.

Changes elsewhere could easily break this, though, so add an
assertion.
Re(mov|writ)e two comments from pad.c:pad_alloc

The thing about "foreach" index vars was added in bbce6d697 (insepar-
able changes from patch from perl5.003_08 to perl5.003_09, presuma-
bly the ‘Lexical scoping cleanup’ part).  It is not valid, because
‘foreach’ doesn’t aliases a pad entry to a non-pad (not marked PADMY
or PADTMP) value until run time, and pad_alloc happens at compile
time.  The real reason we need this loop is that entries that close
over unavailable variables are not marked PADMY.  That may have been a
mistake, but it works because of this loop.  The reason for the loop
also may have changed over time.

The comment about copying to sv is not valid, because it is used later
on in the same condition when compared to &PL_sv_undef.  It was added
in commit dd2155a49b.
pad.c: Use &PL_sv_no for const pad names

Currently &PL_sv_undef as a pad name can indicate either a free slot
available for use by pad_alloc or a slot used by an op target (or,
under ithreads, a constant or GV).

Currently pad_alloc distinguishes between free slots and unnamed slots
based on whether the value in the pad has PADMY or PADTMP set.  If
neither is set, then the slot is free.  If either is set, the slot
is in use.

This makes it rather difficult to distinguish between constants stored
in the pad (under ithreads) and targets.  The latter need to be copied
when referenced, to give the impression that a new scalar is being
returned by an operator each time.  (So \"$a" has to return a refer-
ence to a new scalar each time, but \1 should return the same one.)
Also, constants are shared between recursion levels.  Currently, if
the value is marked READONLY or is a shared hash key scalar, it is
shared.  But targets can also me shared hash keys, resulting in bugs.

It also makes it impossible for the same constant to be shared by mul-
tiple pad slots, as freeing one const op will turn off the PADTMP flag
while the other slot still uses it, making the latter appear to be
free.  Hence a lot of copying occurs under ithreads.  (Actually, that
may not be true any more since 3b1c21fabed, as freed const ops swipe
their constants from the pad.  But right now, a lot of copying does
still happen.)

Also, XS modules may want to create const ops that return the same
mutable SV each time.  That is currently not possible without
various workarounds including custom ops and references.  (See
<https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.)

This commit changes pad_alloc and pad_free to use &PL_sv_no for con-
stants and updates other code to keep all tests passing.  Subsequent
commits will actually use that information to fix bugs.

This will probably break PadWalker, but I think it is an acceptable
trade-off.  The alternative would be to make PadnamePV forever more
complex than necessary, by giving it a special case for &PL_sv_no and
having it return NULL.

I gave PadnameLEN a special case for &PL_sv_undef, so it may appear
that I have simply shifted the complexity around.  But if pad names
stop being SVs, then this exception will simply disappear, since the
global &PL_padname_undef will have 0 in its length field.
pad.c: Expand pad_push SVf_READONLY explanation
op.c: Stop copying constants under ithreads

This fixes bugs #21979, #89188, #109746, #114838 and #115388 and
mostly fixes #109744 and #105906 (other issues still remain in those
two tickets).

Because the PADTMP flag was doing double duty, indicating that a
pad slot was in use in addition to indicating a target, constants
could not be shared between pad slots, as freeing one const op (and
turning of its PADTMP flag in pad_free) would mark some other pad
slot as free.

I believe this may have been fixed already by change 3b1c21fabed,
which made const ops use pad_swipe (which removes the SV from the
pad) instead of pad_free (which marks it as available for reuse).  But
the copying still happens.

In any case, as of the previous commit, whether a pad slot for a con-
stant is in use is now stored in the pad name.  Slots in use for const
ops now have &PL_sv_no names.

So there is no longer any reason to copy the constants.

The difference can be observed thus:

Before:

$ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo'
SV = IV(0x7f94ea02ef10) at 0x7f94ea02ef20
  REFCNT = 2
  FLAGS = (PADTMP,IOK,READONLY,pIOK)
  IV = 42
SV = IV(0x7f94ea02eeb0) at 0x7f94ea02eec0
  REFCNT = 1
  FLAGS = (PADTMP,IOK,READONLY,pIOK)
  IV = 42

After:

$ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo'
SV = IV(0x7f894882ef10) at 0x7f894882ef20
  REFCNT = 3
  FLAGS = (IOK,READONLY,pIOK)
  IV = 42
SV = IV(0x7f894882ef10) at 0x7f894882ef20
  REFCNT = 3
  FLAGS = (IOK,READONLY,pIOK)
  IV = 42

Notice the different addresses.

There are still special cases for copying &PL_sv_undef, which I need
to tackle.

Since most constants created by ‘use constant’ have the PADMY flag on
(since they reside in lexical variables inside constant.pm) and PADMY
and PADTMP are exclusive, I have stop turning on PADTMP for constants.
It is no longer necessary now, since before its purpose was to mark
pad entries as being in use.  That means many to-do tests pass.
pad.c: cast before comparing signed with unsigned
[perl #78194] Make grep/map copy pad tmps

before aliasing them to $_.

And make sure the copies go back on the stack for grep, since modi-
fying $_ in the grep block or expression is supposed to modify the
item returned.
Increase $OptreeCheck::VERSION to 0.10

though I still don’t understand why it has a version at all.
[perl #78194] Make sub calls copy pad tmps

before aliasing them to elements of @_.
constant.t: Correct version

I didn’t have this done in time for 5.19.1.
[perl #3105] Make 1..3 modification safe

This construct is optimised at compile time to an anonymous array with
an implicit @{} around it if both arguments are constant.  Modifying
elements of that array produces wrong results the next time the same
code is executed.

If we mark each element of the array as PADTMP, then it will be
treated like an operator’s return value (which it is) and get copied
as appropriate.