perl.h: Move some macro definitions

This places related definitions together in the file.
locale.c: Always set state variables for a new locale

This function is called when a new underlying LC_NUMERIC locale has been
set.  If that locale is the same as the current underlying one, some
setup is skipped.  However, prior to this commit, more was skipped than
should have been.  The reason is that even if the underlying locale is
the same, it could be that LC_NUMERIC has been toggled to the "C"
locale, and so the information could be inconsistent.  By always setting
the information, we ensure consistency.

This commit ia a portion of the fix for [perl #120723].  Tests will be
added with the final commit for it.
locale.c: White-space only

Outdent code removed from a block by the previous commit
locale.c: Add comments

This documents much of what I learned about how things work while
tracking down [perl #120723].
Hide some undocumented functions from perlapi

These functions should not be called from any other places than they are
now.  They have been marked in the public API as undocumented.  I
presume they are there because they are called from various parts of the
Perl core, so can't be static.  But this suppresses them from being
listed so people won't be tempted to use them.
locale.c: Avoid writing libc static storage

I don't believe this code was causing any problem, but it can overwrite
static storage returned by setlocale().  It's safer to create a copy
first.
perl.h: Revise a locale setting macro

This macro toggles to the C locale.  It should not depend on being in
the scope of 'use locale' to do that, so remove the check.  I couldn't
figure out a test case for this, but I'm pretty sure there is a some
convoluted scheme that this change averts a bug from.
perl.h: Revise another locale setting macro

We generally don't want to switch to the default underlying locale
unless we are in the scope of some form of 'use locale'.  Prior to this
commit, this code did not allow the switch for
'use locale ":not_characters"'.
perl.h: Add macros and comments

These macros are used in making sure the current locale is the correct
one for the circumstances.  I'm not a fan of this type of code
generation macro, but this just extends what is already there, and
aren't all that complicated.
Use new macros to make sure LC_NUMERIC is correctly set

This uses the macros added in the previous commit to make sure the
current LC_NUMERIC locale is correct during the operation being done;
restoring it to its prior condition afterwards.  Outside of 'use locale'
the locale should be C; inside it should be the underlying default
locale.  The macros handle the whole thing.  In most of the places here,
the code was trying to do what the macros do more elegantly, but there
are some additional places where we set the locale correctly around an
operation that is affected by it.
POSIX:strtod() should restore the locale it changed

Prior to this commit, the locale remained as strtod() set it to.  I
could not find a case where this actually was a problem, as the other
code is good about checking for and changing the locale where needed.
But uses of atoi(), strtol() in locales where there are spaces in
numbers likely would break.
vutil.c: Use existing macros instead of reinventing them

If there had been documentation referring to these macros, I would have
known they existed instead of reinventing them (not as well as the
originals).
toke.c: Set locale for all scan_num() calls; restore instead of reset

One call of Perl_scan_num changes the locale around it.  However, this
function is called in several places, including from outside the file.
It is better to set the locale within scan_num() at the point where
it matters.  And, instead of setting the locale unconditionally, it is
better to change it only if it needs to be changed, and restore it to
the original.  Otherwise the locale can be changed to something
unexpected.
numeric.c: White-space only

Indent and reflow to 79 columns as a result of the previous commit's
adding a block around this code.
PATCH: [perl #120723] Setting LC_NUMERIC breaks parsing of constants

This is the final patch for [perl #120723], and adds tests for it.

LC_NUMERIC Locale handling was broken for code during the compilation phase,
such as BEGIN {} blocks.  This is because, for some reason, perl.c set
LC_NUMERIC unconditionally back to the C locale right after locale
initialization.  I suspect that was to allow the core's parsing to not be
affected by locale.  However, earlier commits in this series have added code to
change/restore the locale during sections of the parsing where this might
matter, so this setting to the C locale is not needed.
t/run/locale.t: White-space only

Indent because of new block introduced in the previous commit
APItest.xs: #include fakesdio.h

This causes the printf's and other stdio functions in the file to
instead be the PerlIO equivalents.  We aren't trying to test libc
after all.  See http://markmail.org/message/h26bq75cxlfe3y7r
Merge LC_NUMERIC locale changes branch into blead

LC_NUMERIC hasn't been implemented quite the same way as the other
locale categories.  And the implementation has been somewhat haphazard.
The other categories have implementations where if you're not under
locale you simply use different operations.  That isn't possible with
LC_NUMERIC, as it may need libc functions that are always subject to the
current locale no matter what Perl thinks.

There are two possible implemantation paths that come to my mind to deal
with this.  One is to keep correctly set the locale that the libc
routines need, and switch to the C locale during those places where it
shouldn't be used.  The other way is the opposite, to keep things in the
C locale generally, and switch when needed.

Unfortunately the implementation (prior to this series of commits) used
a combination of both possibilities.  I am still unsure what the
original intent was (not having spent the time to dig through the
history), or even if there was a consistent intent.

In any event, there has long been infrastructure that facilitates
switching back and forth between the current underlying locale and the C
locale.  However this was not documented until now, and so it is not
surprising that people who came later (including me) did not realize
it existed, and reinvented things, inconsistently.

What I've done here is move to the first implementation path mentioned
above.  I believe this is the one more likely to show up other bugs
during the remainder of the 5.19 development cycle.  I have changed and
added to the infrastructure, so that it knows whether we should be in
the C or the underlying locale, and switches/restores if and only if it
is necessary.  We can change to the other implementation path later
with only minimal code changes.