Unicode::UCD: Work on non-ASCII platforms

Now that mktables generates native tables, it is a fairly simple matter
to get Unicode::UCD to work on those platforms.
charnames: Make work in EBCDIC

Now that mktables generates native tables, the only thing that was
needed was to make U+ mean Unicode instead of native.
charnames: fix nit in comment
Add and use macro to return EBCDIC

The conversion from UTF-8 to code point should generally be to the
native code point.  This adds a macro to do that, and converts the
core calls to the existing macro to use the new one instead.  The old
macro is retained for possible backwards compatibility, though it
probably should be deprecated.
Remove EBCDIC remappings

Now that the tables are stored in native format, we shouldn't be doing
remapping.

Note that this assumes that the Latin1 casing tables are stored in
native order; not all of this has been done yet.
toke.c: Remove remapping for EBCDIC for octal

The code prior to this commit converted something like \04 into its
EBCDIC equivalent only in double-quoted strings.  This was not done in
patterns, and so gave inconsistent results.  The correct thing to do
should be to do the native thing, what someone who works on a platform
would think \04 do.  Platform independent characters are available
through \N{}, either by name or by U+.

The comment changed by this was wrong, as in some cases it was native,
and in some cases Unicode.
toke.c: Don't remap \N{} for EBCDIC

Everything is now in native,
Use real illegal UTF-8 byte

The code here was wrong in assuming that \xFF is not legal in UTF-8
encoded strings.  It currently doesn't work due to a bug, but that may
eventually be fixed: [perl #116867].  The comments are also wrong that
all bytes are legal in UTF-EBCDIC.

It turns out that in well-formed UTF-8, the bytes C0 and C1 never appear
(C2, C3, and C4 as well in UTF-EBCDIC), as they would be the start byte
of an illegal overlong sequence.

This creates a #define for an illegal byte using one of the real illegal
ones, and changes the code to use that.

No test is included due to #116867.
toke.c: in [A-Za-z] use macros that exclude non-ASCII alphas

This code is attempting to deal with the problem of holes in the ranges
a-z and A-Z in EBCDIC.  Prior to this patch, it accepeted things like A
WITH GRAVE, etc, which shouldn't have the special processing to deal
with the holes
toke.c: Remove some NATIVE_TO_NEED calls

I believe NATIVE_TO_NEED is defective, and will remove it in a future
commit.  But, just in case I'm wrong, I'm doing it in small steps so
bisects will show the culprit.  This removes the calls to it where the
parameter is clearly invariant under UTF-8 and UTF-EBCDIC, and so the
result can't be other than just the parameter.
Remove remaining calls of NATIVE_TO_NEED

These calls are just copying the input to the output byte by byte.
There is no need to worry about UTF-8 or not, as the output is just an
exact copy of the input
Deprecate NATIVE_TO_NEED and ASCII_TO_NEED

These macros are no longer called in the Perl core.  This commit turns
them into functions so that they can use gcc's deprecation facility.

I believe these were defective right from the beginning, and I have
struggled to understand what's going on.  From the name, it appears
NATIVE_TO_NEED taks a native byte and turns it into UTF-8 if the
appropriate parameter indicates that.  But that is impossible to do
correctly from that API, as for variant characters, it needs to return
two bytes.  It could only work correctly if ch is an I8 byte, which
isn't native, and hence the name would be wrong.

Similar arguments for ASCII_TO_NEED.

The function S_append_utf8_from_native_byte(const U8 byte, U8** dest)
does what I think NATIVE_TO_NEED intended.
handy.h: Combine macros that are same in ASCII, EBCDIC

These 4 macros can have the same RHS for their ASCII and EBCDIC
versions, so no need to duplicate their definitions

This also enables the EBCDIC versions to not have undefined expansions
when compiling without perl.h
handy.h: Simplify some macro definitions

Now, only one of the macros relies on magic numbers (isPRINT), leading
to clearer definitions.
handy.h: Solve a failure to compile problem under EBCDIC

handy.h is included in files that don't include perl.h, and hence not
utf8.h.  We can't rely therefore on the ASCII/EBCDIC conversion
macros being available to us.  The best way to cope is to use the native
ctype functions.  Most, but not all, of the macros in this commit
currently resolve to use those native ones, but a future commit will
change that.
EBCDIC has the unicode bug too

We have not had a working modern Perl on EBCDIC for some years.  When I
started out, comments and code led me to conclude erroneously that
natively it supported semantics for all 256 characters 0-255.  It turns
out that I was wrong; it natively (at least on some platforms) has the
same rules (essentially none) for the characters which don't correspond
to ASCII onees, as the rules for these on ASCII platforms.

A previous commit for 5.18 changed the docs about this issue.  This
current commit forces ASCII rules on EBCDIC platforms (even should there
be one that natively uses all 256).  To get all 256, the same things
like 'use feature "unicode_strings"' must now be done.
utfebcdic.h: Remove trailing spaces
Make casing tables native

These are final tables that haven't been converted to native character
set casing.
t/test.pl: Simplify ord to/from native fcns

This commit changes these functions from converting to/from a string to
calling utf8:: functions which operate on ordinals instead.
t/test.pl: Allow native/latin1 string conversions to work on utf8.

These functions no longer have the hard-coded definitions in them,
but now end up resolving to internal functions, so that new encodings
could be added and these would automatically understand them.

Instead of using tr///, these now go character by character and
converting to/from ord, which is slower, but allows them to operate on
utf8 strings.

Peephole optimization should make these essentially no-ops on ascii
platforms.