Update CPAN-Meta-Requirements to CPAN version 2.123

  [DELTA]

2.123     2013-08-30 12:17:14 America/New_York

    [Fixed]

    - On Perls prior to v5.12, CPAN::Meta::Requirements will be installed
      into the 'core' library path to avoid an older version bundled with
      ExtUtils::MakeMaker and installed there taking precedence.
More changes to perllocale and POSIX.pod setlocale

These address some concerns from John Peacock.
lib/locale.t: Use hash keys instead of many arrays

This implementation detail allows easier handling of things as a whole.
We could save code by adding evals, but I'm trying to not add the added
complexity of evals to the tests here.
lib/locale.t: Display :punct: characters under debug mode

This class of characters was previously omitted
lib/locale.t: Change debug output

This combines the output so that all characters are shown in code point
order, with only ASCII alphanumerics displayed literally.  This is
clearer.
lib/locale.t: Display unassigned chars

This adds debug output to list the characters that aren't matched by any
posix class.
lib/locale.t: Add a bunch of tests

I looked through the online standard and added as many conformance tests
as I could think of.
Make printf, sprintf respect 'use locale' for radix

When called from outside the lexical scope of 'use locale', these now
always print a dot for the decimal point character.

This change is actually done in Perl_sv_vcatpvfn_flags, which is common
to many things, but the principal external effect that I could determine
is on printf and sprintf.

Without this change, unrelated code can change the locale, thus
affecting what an unsuspecting application prints.
lib/locale.t: Refactor some tests

The tests were to make sure that UTF-8 is returned when it should be.
This makes somewhat these somewhat cleaner
Update Module-Load-Conditional to CPAN version 0.58

  [DELTA]

Changes for 0.58    Sun Sep  1 11:21:59 BST 2013
=================================================
* RT#83728 make quoting work portably and remove
  prototypes from one-liner in requires()
Upgrade Scalar-List-Utils from version 1.31 to 1.32
Upgrade Unicode::Collate from version 0.98 to 0.99
perldelta - CPAN::Meta::Requirements has been upgraded
Update parent to CPAN version 0.227

  [DELTA]

0.227  20130991
    . Fix RT #88320, restore tests passing for 5.17.5+
      Thanks to Zefram for the report and contributing the fix
Mention Tk in perl5200delta

See:
https://rt.cpan.org/Ticket/Display.html?id=88210
https://rt.perl.org/rt3//Public/Bug/Display.html?id=118189
perl5200delta: Remove Function::Parameters

1.0202 works with bleadperl.
toke.c: Reorder checks around deprecate_escaped_meta

ckWARN_d involves a function call, so put faster checks first.
test.pl:runperl: more portability warnings

VMS treats initial < > | 2> and trailing & as special in command
line arguments, so we should avoid them in tests.
[perl #115768] improve (caller)[2] line numbers

warn and die have special code (closest_cop) to find a nulled
nextstate op closest to the warn or die op, to get the line number
from it.  This commit extends that capability to caller, so that

  if (1) {
    foo();
  }
  sub foo { warn +(caller)[2] }

shows the right line number.
Fix two line numbers bugs involving quote-like ops

I was going to try and fix #line directives in quote-like operators,
but I found myself fixing bug #3643 at the same time.

Before this commit, the #line directive would last until the end of
the quote-ilke operator, but not beyond:

qq{${
print __LINE__,"\n"; # 43
}};
print __LINE__,"\n"; # 5

The old method:

The lexer would scan to find the closing delimiter after seeing qq{,
incrementing the line number (CopLINE(PL_curcop)) as it went.

Then it would enter a scope for parsing the contents of the string,
with the line number localised and reset to the line of the qq{.

When it finished parsing the contents of qq{...}, it would then pop
the scope, restoring the previous value of the line number.

According to the new method:

When scanning to find the ending delimiter for qq{, the lexer still
increments CopLINE(PL_curcop), but then sets it back immediately to
the line of the first delimiter.

When parsing the contents of qq{...}, the line number is *not* local-
ised.  Instead, that’s when we increment CopLINE(PL_curcop) for real.
Hence, scan_str no longer increments the line number (except before
the starting delimiter).  It is up to callers to handle that *or* call
sublex_push.

There is some special handling for here-docs.  Here-docs’ line numbers
have to increase while the body of the here-doc is being parsed, but
then rewound back to the here-doc marker (<<END) when the code after
it on the same line is parsed.  Then when the next line break is
reached, the line number is incremented by the appropriate number for
it to hop over the here-doc body.  We already have a mechanism for
that, storing the number of lines in lex_shared->herelines.

Parsing of here-docs still happens the old way, with line num-
bers localised to the right scope.  But now we have to move
lex_shared->herelines into the inner scope’s lex_shared struct when
parsing a multiline quote other than a here-doc.

One thing this commit does not handle yet is #line inside a here-doc.

Bug #3643 was one symptom of a larger problem:

During the parsing of the contents of a quote-like operator, the
(localised) line number was incremented only in embedded code snip-
pets, not in constants parts of the string.  So

"${ warn __LINE__,
         __LINE__,
         __LINE__ }"

would correctly give ‘123’.  But this would produce the same
incorrectly:

"
foo
bar
baz
${ warn __LINE__,
         __LINE__,
         __LINE__ }"

Now the parsing of the contents of the string increments the line num-
ber in constant parts, too.