Handle /[#]/ and /[(?#]/ with code blocks

This is a regression in 5.18.0.

In something like /[#](?{})/x, the perl toker incorrectly sees the '#' as a
comment and skips the code block without parsing it.
PATCH: [perl #119101] Extraneous warnings in Parse::ErrorString::Perl

(Since 5.18.0)

This is from https://rt.cpan.org/Ticket/Display.html?id=87458.

Working on this ticket caused me to be more certain of the advisability
of the deprecation message that was added in v5.18.0, and which was
inappropriately being raised in the test suite for this module.

The message notes that escaping the metacharacter '{', '[', or '(')
doesn't actually do anything in a pattern whose delimiters are {} [] or
() respectively.

The code in question looked something like

    my $pat = "m{\Q$foo}";
    ...
    eval "$bar =~ $pat";

where $foo comes from somewhere else and contained something like
\x{61}.  The message should not be raised because the \Q changes that to
\\x\{61\}, and so the \x loses its special meaning as well, and the left
brace is not a metacharacter in this context.  The solution is to look
at all the backslashes before the 'x' and only raise the message if
there are an odd number of them.

But, if $foo had been something like "bar{3}", the \Q would have
transformed that into "bar\{3\}.  In the code above, this matches
"b" followed by "a" followed by 3 "r"s.

Similarly for [] and ().

    my $foo = "(abc)";
    my $pat = "m(\Q$foo)";
    ...
    eval "$bar =~ $pat";

will not match the parens in $foo literally, but treat them as marking a
group.

The bottom line is that currently you cannot rely on \Q to properly
quote in a regex pattern in which the delimiters are mirrored
metacharacters.  The only current safe mirrored delimiters are <>, which
are not metacharacters.  Starting in 5.18.0, there is a default-on
message that catches this.  Starting with this commit, certain false
positives have been removed, and I know of none other.
Note that three more test files are excluded from XSLoader
Use undef rather than 'undef' for Devel::PPPort's UPSTREAM status

All other undefined UPSTREAM statuses are undef rather than 'undef'
already, which causes core-cpan-diff to emit 'upstream is: UNKNOWN!'
rather than 'upstream is: undef', which is probably the intended effect
since it indicates the status is not known rather than specifically
undefined.
Set a large thread stack when running the regex tests in a thread.

For testing ithreads cloning, all the regex tests are run twice. Once
"normally", and once in a child ithread, to verify that all regex
constructions can be cloned.

The recently added tests for backreferences starting with 8 or 9 causes a
lot of C recursion in the child thread, enough to bust the default thread
stack size on (at least) HP-UX. So set a large explicit thread stack size.
It doesn't matter that it's large, as we are only running one child thread.
version's test files are not excluded from blead

They were added long ago by 543eec9e19.
Extend sv_dump() to dump SVt_INVLIST

This changes the previously unused _invlist_dump() function to be called
from sv_dump() to dump inversion list scalars.  The format for regular
SVt_PVs doesn't give human-friendly output for these.

Since these lists are currently not visible outside the Perl core, the
format is documented only in comments in the function itself.
dump.c: White-space only

Indent and wrap lines to correspond with newly formed block
Update Scalar-List-Utils to CPAN version 1.29

  [DELTA]

1.29 -- Thu Aug 01 13:40 UTC 2013

  * Bugfix to pairmap/pairgrep when stack moves beneath them during operation

1.28 -- Thu Aug 01 12:19 UTC 2013
  -- BROKEN; do not use. See 1.29

  * Added pairgrep, pairmap, pairs (inspired by List::Pairwise)
  * Added pairkeys and pairvalues
regcomp.c: Silence clang compiler warning

There is no pre-canned format for printing STRLEN variables.  This
commit casts to UV and uses %"UVuf".
prevent a precedence warning on clang

Dumper.xs:245:29: warning: '&&' within '||' [-Wlogical-op-parentheses]
                   ((k >= 7 && k <= 10 || k == 12 || k == 13 || k == 27)
                     ~~~~~~~^~~~~~~~~~ ~~
Dumper.xs:245:29: note: place parentheses around the '&&' expression to silence
      this warning
                   ((k >= 7 && k <= 10 || k == 12 || k == 13 || k == 27)
Regression tests for 4 cases reported by Philip Hazel++.

With revisions per suggestion by demerphq++.
For: RT #119069, 119071, 119073, 119075
Update CPAN-Meta to CPAN version 2.132140

  [DELTA]

2.132140  2013-08-02 11:54:17 America/New_York

  [DOCUMENTATION]

  - Fixed some typos in CPAN::Meta::Spec

  [OTHER]

  - migrated repository to Perl-Toolchain-Gang organization on Github and
    updated metadata accordingly
Add note about regenerating META files when updating CPAN-Meta
Resolve File::Spec test failures on QNX Neutrino
_perl_abs_path() symlink tests fail on QNX Neutrino
Revert "[perl #119043] Exempt shared hash key consts from ro"

This reverts commit ba36554e02872e48d146177a57a9cfb154727fae.

It turns out it reinstates bugs like this:

$ perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}'
main at -e line 1.
maio at -e line 1.
maip at -e line 1.
maiq at -e line 1.
mair at -e line 1.
mais at -e line 1.
mait at -e line 1.
maiu at -e line 1.
maiv at -e line 1.
maiw at -e line 1.
Test that __PACKAGE__ is read-only

I.e., test that this bug is fixed:

$ perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}'
main at -e line 1.
maio at -e line 1.
maip at -e line 1.
maiq at -e line 1.
mair at -e line 1.
mais at -e line 1.
mait at -e line 1.
maiu at -e line 1.
maiv at -e line 1.
maiw at -e line 1.

for my$p(__PACKAGE__){$p++for+1..55664
,;!print"Just another \u$p hacker,\n"}
[perl #119043] Allow utf8 up/downgrade on ro COWs

Commit 1913067 allowed COW constants to be read-only.  This broke
Glib, so I reverted it with ba36554e02.  That caused this bug to reë-
merge (I hadn’t realised that I had fixed it in 1913067):

perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}'
main at -e line 1.
maio at -e line 1.
maip at -e line 1.
maiq at -e line 1.
mair at -e line 1.

so I reverted the revert two commits ago.

Glib was triggering a read-only error because it called
sv_utf8_upgrade on a read-only COW scalar, and sv_utf8_upgrade does
sv_force_normal on COWs to de-COW them.  sv_force_normal croaks on
read-only scalars.

The real problem here is that sv_force_normal means ‘I am going to
modify this scalar’, yet sv_utf8_upgrade conceptually does not modify
the scalar, but only changes the internal representation.

Having to call sv_force_normal to get the *side effect* of de-COWing
without triggering the various other things it does is no good.

What we need is a separate sv_uncow function that sv_force_normal
uses.  This commit introduces such a function.
Don’t let list const modification affect future retvals

In commit f99a5f08f203, I inadvertently made modifications to val-
ues return by list ‘constants’ affect what values are returned sub-
sequently.

It’s for this type of situation that PADTMP exists (values are never
referenced, but copied).  So use it.

This is similar to 5608dcc62, which fixed #3105.