Update ExtUtils-MakeMaker to CPAN version 6.94

  [DELTA]

6.94 Tue Mar 25 19:26:31 GMT 2014

    No changes from 6.93_01

6.93_01 Mon Mar 24 16:53:31 GMT 2014
    Bug fixes:
    * Resolved a regression in MM_Unix.pm
      (https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/96)
[perl #121366] avoid using an invalid SvPVX() in Perl_sv_pvn_force_flags

This would cause valgrind to complain about:

  vec($Foo, 0, 1) = 1; # for example

when $Foo was undef, since SvPVX()[1] isn't initialized until the SV is
at least a SVt_PV.

[1] well, sv_u.svu_rv, but sv_u is a union, so the same memory is
initialized.  This isn't technically legal from a C point of view,
but pointer types are compatible enough with each other for it to not
be an issue.
Deprecate /\C/

For 5.20, just say its deprecated. We'll add a warning in 5.22
and change its behaviour in 5.24.
Revert "Add support for test.valgrind parallel testing"

This reverts commit f0aff2daa44923f600f6e1f2429a2add2214a9d5
"Add support for test.valgrind parallel testing"

This patch was accidentally pushed (by me); it breaks some things.  We
will wait to add this support until after 5.20
perlrebackslash, perlreref.pod: White space only

Fit verbatim lines into 79 columns
fix killpg on Win32, to meet posix expectations for killpg

On Win32 Perls built without PERL_IMPLICIT_SYS, killpg from win32.c was
directly called by Perl_apply, yet killpg's return value had Win32
behavior, not POSIX behavior. Modify killpg token to have same meaning as
PerlProcKillpg/PerlProc_killpg has on PERL_IMPLICIT_SYS builds. Use a
macro rather than create a win32_killpg C function since win32_killpg would
be nothing but a call to win32_kill anyways. win32_kill contains the Win32
to POSIX semantics conversion code. Rename old killpg to my_killpg since
it has no use outside of win32.c. The psuedo-PID code in win32_kill also
played a factor in not writing a separate win32_killpg that calls
my_killpg. This fix is tested by kill0.t passing on
no-PERL_IMPLICIT_SYS builds.

[perl #121230]
Maintainers.pl synchronised for CPAN release of ExtUtils-Install
RMG - we no longer have UPSTREAM => 'undef' in Porting/Maintainers.pl
RMG - note that CPAN module upgrades are subject to code freeze restrictions

(As confirmed on p5p by RJBS on 24 March 2014.)
RMG - refer to BLEAD-POINT/BLEAD-FINAL releases for consistency and clarity
perldelta: /\C/ will be an error in 5.24

Update the recently added perldelta entry to say that /\C/ will become an
error rather than becoming equal to /./.
Commit b776cec188 missed these RMG steps when preparing Module::CoreList for 5.19.11
Start updating perldelta for 5.19.11
Reword Windows makefile comments to explain the "help" logic about USE_MULTI

There is logic to auto-enable USE_MULTI if either USE_ITHREADS or USE_IMP_SYS
(which both require USE_MULTI) are enabled, but this is not mentioned in
the comments. Explain it so that users don't get confused when trying to
disable USE_MULTI.

Reported in [perl #121494].
missing word in perl5200delta.pod

I missed out "will" in
1ffb44d62eaa2f08535ed009ec13d81bfb7ad840
mg.c: Fix comment typo
perllocale: Note that $^E acts the same as $!
perllocale: Nits

The hyperlink text looks wrong in html
PATCH: [perl 121317] Gconvert() obeys LC_NUMERIC without "use locale"

This reverts part of bc8ec7cc020d0562094a551b280fd3f32bf5eb04.
leaving LC_NUMERIC set to the C locale at start-up.  This allows the
tests for quite a few XS modules to pass, as they (and likely the
modules themselves) are expecting a dot as the decimal point character.
However,such modules remain vulnerable to explicit calls to setlocale()
by the Perl code or other modules,

See the ticket's discussion for ideas on how to fix this better in 5.21
going forward.

I did not add tests because this fix only affects XS code that is not in
the Perl API, and we don't have any infrastructure for testing that.
Building such infrastructure seems to me to be too much for the code
freeze situation we are in, and all this is planned to change very early
in v5.21 anyway.
PATCH: [perl #119499] "$!" with UTF-8 flag

This disables the code that sets the UTF-8 flag when "$!" is UTF-8.
This is being done to get v5.20 out the door, with changes to follow in
v5.21.  See towards the end of the discussion of this ticket.

Unfortunately this change will cause #112208 to no longer be fixed.