sv.h: Add comment
locale.c: Add comments
locale.c: Add assert()

This function is static and currently isn't called with LC_ALL, nor
would it work properly if it were called with that parameter, so assert
against it
perl.h, locale.c: White space only

This indents some nested #if's to clarify the program structure.
locale.c: Compare apples to apples

Prior to this patch, one parameter to strNE would have been through a
standardizing function, while the other had not.  By standardizing both
before doing the compare, we avoid false positives.
locale.c: Extract out, fix, expand fcn to see if a locale is utf8

There was buggy code to see if the start-up locale is UTF-8.  This
commit extracts it into a separate function.

The bugs involved looking at the name of the locale to see if that
implies a UTF-8 name.  Prior to this commit, it looked at the
beginning of the locale name, whereas in reality, it is at the end, as
in "fr_FR.UTF8".

Also, it didn't look for the documented Windows name for UTF-8 locales
on those platforms.

The function is expanded to have an input category to find the utf8ness
of.  Thus it now works on any non-LC_ALL category, not just LC_CTYPE.

It is possible for categories to be in different locales, so that
LC_CTYPE is in a UTF-8 locale, and LC_NUMERIC isn't.  For the purposes
of PERL_UNICODE, the most applicable category is LC_CTYPE, so that is
the one used.
XXX segfault on dromedary, ps_AF fails locale.c; special case C and POSIX: Further checks for utf8ness of a locale

In reality, the return value of setlocale() is supposedly opaque, so
using it to determine if a locale is UTF-8 or not may not work.  We can
safely assume that if the name contains UTF-8 (or slight variations
thereof), that it is a UTF-8 locale.  But if the name doesn't contain
that, it still could be one.  In fact there are currently many locales
on our dromedary machine that fall into this category.

This commit adds another test for that.  strerror(), the source for $!,
returns its strings based on the LC_MESSAGES locale.  This commit looks
at those messages; if any isn't valid UTF-8, the locale won't be
considered to be UTF-8.  The chances are vanishingly small that other
encodings will pass UTF-8 validity tests over all the messages.
If all the messages are entirely ASCII, this check hasn't helped us;
this commit assumes non-UTF-8 for this case.

Note that this test will run only on systems that don't have
nl_langinfo(), which is reliable if present.  The test can also be
turned off by setting a C compiler flag -DNO_LOCALE_MESSAGES,
corresponding to the way the other categories can be turned off
(none of which is documented).
PATCH: [perl #112208]: Set utf8 flag on $! appropriately

This patch sets the utf8 flag on $! if the error string passes utf8
validity tests and has some bytes with the upper bit set.  (If none
have that bit set, is an ASCII string, and whether or not it is UTF-8 is
irrelevant.)  This is a heuristic that could fail, but as the reference
in the comments points out this is unlikely.

One can reasonably assume that a UTF-8 locale will return a UTF-8
result.  So another approach would be to look at that (but we wouldn't
want to turn the flag on for a purely ASCII string anyway, as that could
change the semantics from existing behavior by making the string follow
Unicode rules, whereas it didn't necessarily before.)  To do this, we
could keep track of the utf8ness of the LC_MESSAGES locale.  But until
the heuristic in this patch is shown to not be good enough, I don't see
the need to do this extra work.
Properly determine if in locale for NV stringification

Commit 68e8f474bc686a86c064b695b9c7400313d7af65 used the wrong macro to
determine if the operation is within the scope of 'use locale'.  It also
has to operate under 'use locale 'not_characters'.

Tests for this are coming in the patch for [perl #118197].
PATCH: [perl #118197] Cope with non-ASCII decimal separators

This patch causes the radix string to be examined upon a new numeric
locale being set.  If the string isn't ASCII, and the new locale is
UTF-8, it turns on the UTF-8 flag in the scalar that holds the radix.
When a floating point number is formatted in Perl_sv_vcatpvfn_flags(),
and the flag is on, the result's flag will be set on too.
util.c: Avoid unnecessary setlocale() calls

This code sets the locale to C around its work.  This is unnecessary if
the locale is already C, and there is an existing global that indicates
this, that can be tested to avoid the sets.
pp_sys.c: Use macro instead of reinventing it

The Strerror macro is defined properly to handle either case here.
perl.c: Use Strerror instead of strerror

The former works on more systems.