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.
Adjust conflicting documentation about \s vis-à-vis \cK

# New Ticket Created by  Thomas Sibley
# Please include the string:  [perl #121558]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=121558 >

See attached patch against blead.

>From 84a704858995060ef78a39372ca7e2572c6141a3 Mon Sep 17 00:00:00 2001
From: Thomas Sibley <tsibley@cpan.org>
Date: Tue, 1 Apr 2014 13:49:26 -0700
Subject: [PATCH] =?UTF-8?q?Adjust=20conflicting=20documentation=20about=20?=
 =?UTF-8?q?\s=20vis-=C3=A0-vis=20\cK?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It makes little sense to say that \s matches \cK unconditionally in the
same sentence as saying it matches \cK conditionally (>= Perl 5.18).

I suppose the intention could have been to specify the full char class
in the documentation from 5.18 onwards while still noting when that
change happened (the introducing commit, d28d802, was only on 5.17+),
but the sentence structure and convention in the rest of the document
suggests otherwise.
Fix comments and pod that mention 5.20 erroneously

In certain places in the documentation, "5.20" is no longer applicable.
Also, a message referred to in perldiag got reworded, but our checks did
not catch that perldiag should have been updated.
utf8: add tests for behavior change in v5.15.6-407-gc710240, and more

In v5.15.6-407-gc710240 Father Chrysostomos patched utf8::decode() so it
would call SvPV_force_nolen() on its argument. This meant that calling
utf8::decode() with a non-blessed non-overloaded reference would now
coerce the reference scalar to a string, i.e. before we'd do:

    $ ./perl -Ilib -MDevel::Peek -wle 'use strict; print $]; my $s = shift; my $s_ref = \$s; utf8::decode($s_ref); Dump $s_ref; print $$s_ref' ævar
    5.019011
    SV = IV(0x2579fd8) at 0x2579fe8
      REFCNT = 1
      FLAGS = (PADMY,ROK)
      RV = 0x25c33d8
      SV = PV(0x257ab08) at 0x25c33d8
        REFCNT = 2
        FLAGS = (PADMY,POK,pPOK)
        PV = 0x25a1338 "\303\246var"\0
        CUR = 5
        LEN = 16
    ævar

But after calling SvPV_force_nolen(sv) we'd instead do:

    $ ./perl -Ilib -MDevel::Peek -wle 'use strict; print $]; my $s = shift; my $s_ref = \$s; utf8::decode($s_ref); Dump $s_ref; print $$s_ref' ævar
    5.019011
    SV = PVIV(0x140e4b8) at 0x13e7fe8
      REFCNT = 1
      FLAGS = (PADMY,POK,pPOK)
      IV = 0
      PV = 0x140c578 "SCALAR(0x14313d8)"\0
      CUR = 17
      LEN = 24
    Can't use string ("SCALAR(0x14313d8)") as a SCALAR ref while "strict refs" in use at -e line 1.

I think this is arguably the right thing to do, we wouln't actually utf8
decode the containing scalar so this reveals bugs in code that passed
references to utf8::decode(), what you want is to do this instead:

    $ ./perl -CO -Ilib -MDevel::Peek -wle 'use strict; print $]; my $s = shift; my $s_ref = \$s; utf8::decode($$s_ref); Dump $s_ref; print $$s_ref' ævar
    5.019011
    SV = IV(0x1aa8fd8) at 0x1aa8fe8
      REFCNT = 1
      FLAGS = (PADMY,ROK)
      RV = 0x1af23d8
      SV = PV(0x1aa9b08) at 0x1af23d8
        REFCNT = 2
        FLAGS = (PADMY,POK,pPOK,UTF8)
        PV = 0x1ad0338 "\303\246var"\0 [UTF8 "\x{e6}var"]
        CUR = 5
        LEN = 16
    ævar

However I think we should be more consistent here, e.g. we'll die when
utf8::upgrade() gets passed a reference, but utf8::downgrade() just
passes it through. I'll file a bug for that separately.
Add pod/perl5182delta.pod
RMG - Update note about adding new perldelta in BLEAD-FINAL/MAINT releases