Fix for RT #118169

https://rt.perl.org/rt3/Public/Bug/Display.html?id=118169

subroutine arguments are no longer shown in perl debugger ( x @_ in perl
-d) .

Regression from perl-5.16.x due to the perl -d refactoring. Fixed with a
test.
Fix the mutability of @_ in perl -d.

With a test.

See Father C.'s comment on RT #118169.
perldelta for debugger @_ fix
Fix regmatch pointer 32-bit wraparound regression

Cherry-picked from:

commit 285a3ca139d04d2ee1894c9a9110294ee8bb0309
Merge: aad0429 dfb8f19
Author:     Tony Cook <tony@develop-help.com>
AuthorDate: Mon Jun 3 22:28:37 2013 +1000
Commit:     Tony Cook <tony@develop-help.com>
CommitDate: Mon Jun 3 22:28:37 2013 +1000

    [perl #118175] avoid making pointers outside of objects

    In a couple of cases, when strings were allocated above the 2GB line
    on 32-bit CPUs, this could cause regexps to act strangely - not matching
    or crashing perl.

    The final patch in the set prevents pointer creation which the C standard
    describes as undefined behaviour, but is typically safe (as long as the
    pointer isn't derefed)

This regression was introduced into 5.18.0 by commit
4063ade8503ac8877a02fc4eae8ebbe242b9110b.
[perl #118159] Make PVs take precedence in SvTRUE

Commit 4bac9ae4 (probably inadvertently) changed SvTRUE to treat an SV
with any of PVX, IVX or NVX having a true value as true.

Traditionally, truth was based solely on stringification. The examina-
tion of the SvIVX and SvNVX slots was for those cases where there was
no string already and it could be deduced from IVX or NVX whether it
would stringify as "0" or no (bugs with -0 aside).

This changes things back to the way they have ‘always’ been.

This was a regression in 5.18.0;
cherry-picked from 762dbf22cb22645771fc27b5d197fd40cbbd9da8.
Ensure that the IV in struct pmop (for ithreads) is aligned properly.

Regression in 5.18.0 cherry-picked from
c2a50ddb1bed657609ef5e85c7ac5c0bfcaa2c9a

The members of struct pmop vary between ithreads and non-ithreads builds.
For ithreads, an IV is used for op_pmoffset. For 32 bit platforms built
with -Duse64bitint, IVs are 64 bits, but pointers (and all other members of
all OP structures) are 32 bits, hence on 32 bit platforms OP structure sizes
can be an odd multiple of 4 bytes. Since the swap to the slab allocator,
this is causing problems on architectures where 8 byte IVs have to be 8
byte aligned, notably sparcs. The long-term fix is to replace the IV with
an appropriate 32 bit type, as it is being used for an array index. However,
for maint-5.18 we need a work around which doesn't change the public headers
and ideally doesn't impose a large speed or memory penalty.

Hence for now, simply avoid using the slab allocator when allocating a
struct pmop. Only do this for 32 bit platforms build with 8 byte IVs and
ithreads.

This is the interim fix for RT #118055.
update perldelta with recent cherry-picks