This is a follow-up to 12f55bbce575aecc, which fell victim to a
bug workaround. Because the broken pipes on VMS sometimes put
multiple blank lines in test output, we collapse multiple newlines
into one. Which breaks tests that genuinely have multiple blank
lines in the output.

So don't leave the output blank, which coincidentally makes it a
lot easier to see which print statement produces which line of
output.

Furthermore, make the GCC_DIAG_IGNORE and _RESTORE to be dNOOPs,
so that they can be at any level of the code, including global, even
when the compiler is not gcc (or lookalike). If they are just empty,
";" will be left at the call site.

This problem turns out to be a misspelling in two places of a compiler
definition. Since the definition didn't exist (as it was misspelled),
the #ifdef failed.

I don't know how really to test this as it is locale collation, which
varies by locale, and we would be relying on vendor-supplied locales
which may be inconsistent between platforms. I intend to tackle
improvements to collaction later this release cycle, and should come up
with tests at that time. The failing tests in the module were comparing
the Perl sort results with those of the module, and finding they differ.

On netbsd, not all locales have an LC_TIME, and so they are all failing
the tests for that. This is true even though they have LC_ALL. I don't
know if that is legal or not, but Perl can't do anything about it, so
this skips the LC_TIME tests for locales that don't have it.

The debugging statements should begin with a '#' so TAP ignores them.
It's easier to do this in the subroutine that prints them, rather than
remember to do so in each call to it. This doesn't change the few
debugf() calls, because one doesn't want a # (it just outputs an empty
line)

'use encoding "latin1"' has the effect of causing \x80 - \xFF to be
treated as Unicode characters in a regular expression, which is the same
thing as the /u modifier does. The pragma may eventually be removed, so
replace it by the more modern way to get the same effect

I consider this experimental, so that if code breaks as a result, we
will remove it.

I chose the numeric warnings category. But misc or a new subcategory of
numeric might be better choices.

There is also the issue if someone is calculating the repeat count in
floating point and gets something that would be 0 if there were infinite
precision, but ends up being a very small negative number. The current
implementation will warn on that, but probably shouldn't. I suspect that
this would be extremely rare in practice.

- after return/croak/die/exit, return/break are pointless
(break is not a terminator/separator, it's a goto)
- after goto, another goto (!) is pointless
- in some cases (usually function ends) introduce explicit NOT_REACHED
to make the noreturn nature clearer (do not do this everywhere, though,
since that would mean adding NOT_REACHED after every croak)
- for the added NOT_REACHED also add /* NOTREACHED */ since
NOT_REACHED is for gcc (and VC), while the comment is for linters
- declaring variables in switch blocks is just too fragile:
it kind of works for narrowing the scope (which is nice),
but breaks the moment there are initializations for the variables
(the initializations will be skipped since the flow will bypass
the start of the block); in some easy cases simply hoist the declarations
out of the block and move them earlier

Note 1: Since after this patch the core is not yet -Wunreachable-code
clean, not enabling that via cflags.SH, one needs to -Accflags=... it.

Note 2: At least with the older gcc 4.4.7 there are far too many
"unreachable code" warnings, which seem to go away with gcc 4.8,
maybe better flow control analysis. Therefore, the warning should
eventually be enabled only for modernish gccs (what about clang and
Intel cc?)

Files like dist/Math-BigInt/lib/Math/BigInt.pm are probably going to remain in
known_pod_issues.dat for eternity, given that in POD the cumulative effect of
'=over' markings will always result in linelengths > recommended 79 or 80.