perldiag - Restore nitpick corrections

These were corrected in 4a70680af1 but then undone (presumably by
accident) in 727b63796f.
perldelta updates
PERL_GLOBAL_STRUCT threads issue

A test in op/threads.t roughly equivalent to this:

    use threads;
    sub f {};
    async \&f;

was randomly failing smokes under the combination of PERL_GLOBAL_STRUCT and
ASan.

This is due to the fact that, under PERL_GLOBAL_STRUCT, "global" vars
are actually allocated, and are freed as the very last thing before
exiting (later than perl_destruct()). In the code above, the created
thread is still exeecuting at this point, and so may access those "global"
vars.  ASan can detect that such a var is being accessed after being
freed; in this case due to PL_ppaddr being indexed in call_sv().

This is easily fixed using the PL_veto_cleanup mechanism; don't do those
final frees if there are still threads running.
gcc 4.9 by default does some optimizations that break perl (#121505)

Patch by Tony Cook
-fwrapv is broken prior to gcc-4.3 (googled and patched by Zefram)
Upgrade CPAN from 2.04-TRIAL to 2.05-TRIAL
Make perlbug encoding-agnostic in handling prepared reports.

Guessing the encoding of a report file prepared ahead of time is
really, well, too much guesswork, plus there are at least a couple
of mistakes in the implementation.  And we weren't even trying to
guess for reports created on-the-fly in an editor, which is a bit
inconsistent.

So handle prepared reports the same way as on-the-fly reports and
attachments, which means all I/O is done using the :raw layer.

This is only "Unicode-aware" in the sense that we're aware there
are a lot of encodings out there and we're trying not to mangle
them in transit by accidental conversion.  We're not doing any
explicit character set conversions and we shouldn't assert in the
MIME headers that we know what character set we're sending because
we don't.
Attempt to satisfy CRLF expectations in perlbug on Windows.
initialise PL_watch_pvx

This global var is only used in debugging builds, but with
PERL_GLOBAL_STRUCT_PRIVATE builds, it gives valgrind errors. Just
initialise it to NULL.

I was originally trying to replicate smoke failures of
dist/Thread-Queue/t/07_lock.t under PERL_GLOBAL_STRUCT_PRIVATE, and
valgrind complained.
PATCH: [perl #90646] perlop.pod: Clarify & | and ^ binary operations
POSIX.pod: Nits

Most of the changes are to add C<> around code snippets, like function
macro and constant names.

There are a couple of grammar changes.

The only sort-of substantive change is that strtod() does respect
setlocale.  Previously it said it *should* respect setlocale.
PerlIO.pm: Make pod :utf8 caution more prominent

The :utf8 layer continues to have security issues.  This moves the
warning about that to earlier where it's more likely to be seen, and
makes it stand out more.
[perl #120998] avoid caller() crashing on eval '' stack frames

Starting from v5.17.3-150-g19bcb54e caller() on an eval frame would
end up calling Perl_sv_grow() with newlen = 0xFFFFFFFF on 32-bit
systems.

This eventually started segfaulting with v5.19.0-442-gcbcb2a1 which
added code to round up allocations to the nearest 0x100, setting
newlen to 0, faulting when sv_setpvn() attempted to copy its source
string into the zero space provided.
ExtUtils::Install handle symbolic and hard links

[perl #72028]

When upgrading an already-installed file, ExtUtils::Install could mess up
the permissions of files if the old versions of files were hard or
symbolic links. For example, if the Foo module had been installed as
lib/Foo.pm and for some reason (perhaps due to OS packaging) that file was
hard-linked to other/Foo.pm or replaced with a symbolic link to
other/Foo.pm, then when trying to install a newer release of Foo, the
permissions of the other/Foo.pm file could end up messed up.

This was due to ExtUtils::Install changing the permissions of the old file
before unlinking it; if the file was a link, then the linked file would
get the chmod instead. Since on POSIXy platforms it is the directory
permissions, not the file permissions, that affect whether a file can be
unlinked, the chmod was redundant anyway. So on these platforms, skip the
chmod.

I've also added tests for symlinked and hard-linked files.
perldelta updates
run/locale.t: silence shell warnings

A couple of tests do

    local $ENV{LC_ALL} = "invalid";
    fresh_perl_is(...);

this causes a shell to be invoked with an invalid locale. Some shells
such as bash, become very noisy in this case:

    $ LC_ALL=invalid /bin/sh -c 'echo yes'
    /bin/sh: warning: setlocale: LC_ALL: cannot change locale (invalid): No such file or directory
    yes
    $

Silence these warnings by temporarily closing STDERR. Since the
fresh_perl_is() scripts themselves are run with STDERR set to /dev/null
anyway, this isn't a hardship.
run/locale.t: reindent block

Re-indent a block of code after the previous commit added an extra scope.
Whitespace-only change
perldelta: add entry for //m fix
Update perldelta for #121512 (9fdd5a7ac7)
Bump ExtUtils::Install version to 1.65