op.c: Use macro instead of its expansion

It's better to use a pre-defined macro when available.  This isn't quite
the same, as the macro is valid for both run-time and compile-time and
the code is only compile-time.  In the unlikely event that  this were
ever to be found to be other than negligible, a compile-time-only
version of the macro could be created.
numeric.c: Remove unnecessary test

The second test won't be true unless the first one is (but not vice
versa), so no need to test the first.
Add parameters to "use locale"

This commit allows one to specify to enable locale-awareness for only a
specified subset of the locale categories.  Thus you could make a
section of code LC_MESSAGES aware, with no locale-awareness for the
other categories.
Data::Dumper: Fix wrong #if

The code being conditionally compiled is for LC_COLLATE, not LC_NUMERIC
Use C locale for "$!" ouside 'use locale' scope

The stringification of $! has long been an outlier in Perl locale
handling.  The theory has been that these operating system messages are
likely to be of use to the final user, and should be in their language.
Things like
    No space left on device
    Can't fork
are not something the program is likely to handle, but could be
meaningfully helpful to the end-user.

There are problems with this though.  One is that many perl messages are
in English, with the $! appended to them, so that the resultant message
is of mixed language, and may need to be translated anyway.  Things like
    No space left on device
probably won't need the remaining portion of the message to give someone
a clear indication as to what's wrong.  But there are many other
messages where both the OS error and the Perl error would be needed
togther to understand the problem.  An on-line translation tool can be
used to do this.

Another problem is that it can lead to garbage coming out on the user's
terminal when the program is not expecting UTF-8, but the underlying
locale is UTF-8.  This is what happens in Bug #112208, and another that
was merged with it.  It's a lot harder to translate mojibake via an
online tool than English.

This commit solves that by using the C locale for messages, except
within the scope of 'use locale'.  It is extremely likely that the
messages in the C locale will be English, but if not they will be ASCII,
and there will be no garbage printed.  A program that says "use locale"
is indicating that it has the intelligence necessary to deal with
locales.
Revert "PATCH: [perl #119499] "$!" with UTF-8 flag"

This reverts commit b17e32ea3ba5ef7362d2a3d1a433661afb897786.

With this commit, the stringification of $! will have the UTF-8 flag set
when the text is actually non-ASCII UTF-8.  The reverted commit itself
reverted code that was to fix bugs with this discrepancy of the UTF-8
flag, but which caused backward-compatibility problems with existing
code.

Several things have happened in the interim which allows us to
experimentally resotre the previously reverted changes.  One is that
this is early in the 5.21 cycle, and we have plenty of time to see what
negative consequences this may cause.  Two is that the returned text
will only be in UTF-8 if the stringification happens within the scope of
'use locale'.  This means that the negative effects won't happen for
code, like ack, that is otherwise locale unaware.  Third, the 'locale'
pragma has been enhanced to allow the program to only have locale
awareness of LC_MESSAGES.

Code that needs to continue the 5.20 and earlier behavior can do the
stringification within the scopes of both 'use bytes' and 'use locale
":messages".  No other Perl operations will be affected by locale; only
$! and $^E stringification.  The 'bytes' pragma causes the UTF-8 flag to
not be set, just as in previous Perl releases.
Fix Windows ctype functions

Windows doesn't follow the Posix standard for their functions like
isalnum(), isdigit(), etc.  This forces compliance by changing the
macros that are the interfaces to those functions to be smarter than
just calling the raw functions.
t/run/locale.t: Remove unnecessary setlocales()

The locale is supposed to be passed in via the environment.  There is no
need to also set it explicitly.