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
Set Off_t et al correctly for USE_LARGE_FILES builds on Windows

The canned config files used to build miniperl.exe (with some updates
applied by Makefile / makefile.mk) have the non-USE_LARGE_FILES settings
for Off_t, LSEEKSIZE and Off_t_size, resulting in an uninitialized memory
read in win32_fseek() in miniperl.exe, which recently started causing
exetype.pl to write a 4GB wperl.exe during the build of a 64-bit perl.

Change Makefile / makefile.mk to use the correct settings for the build of
miniperl.exe. This fixes perl #121471.
Fix DllMain definition to fix building with gcc-4.8.1 from www.mingw.org

This partly fixes perl #121643.
Remove unused variable
perldelta for e141190569
perldelta for 78beb4ca6d
Upgrade Win32 from version 0.48 to 0.49

This fixes the build with gcc-4.8.1 from http://www.mingw.org and thus
resolves perl #121643.