utf8.c: is_utf8_char_slow() should use native length

What is passed is the actual length of the native utf8 character.  What
this was calculating was the length it would be if it were a Unicode
character, and then compares, apples to oranges.
pp_ctl.c: Use isCNTRL instead of hard-coded mask

This is clearer and portable to EBCDIC.
utf8.h, utfebcdic.h: Create less confusing #defines

This commit creates macros whose names mean something to me, and I don't
find confusing.  The older names are retained for backwards
compatibility.  Future commits will fix bugs I introduced from
misunderstanding the meaning of the older names.

The older names are now #defined in terms of the newer ones, and moved
so that they are only defined once, valid for both ASCII and EBCDIC
platforms.
Use new clearer named #defines

This converts several areas of code to use the more clearly named macros
introduced in a recent commit
Use byte domain EBCDIC/LATIN1 macro where appropriate

The macros like NATIVE_TO_UNI will work on EBCDIC, but operate on the
whole Unicode range.  In the locations affected by this commit, it is
known that the domain is limited to a single byte, so the simpler ones
whose names contain LATIN1 may be used.

On ASCII platforms, all the macros are null, so there is no effective
change.
Don't use EBCDIC macro for a C language escape

C recognizes '\a' (for BEL); just use that instead of a look-up.

regen/unicode_constants.pl could be used to generate the character for
the ESC (set in surrounding code), but I didn't do that because of
potential bootstrapping problems when porting to an EBCDIC platform
without a working perl.  (The other characters generated in that .pl are
less likely to cause problems when compiling perl.)
Extract common code to an inline function

This fairly short paradigm is repeated in several places; a later commit
will improve it.
utf8.h: Correct macros for EBCDIC

These macros were incorrect for EBCDIC.  The 3 step process given in
utfebcdic.h wasn't being followed.
Remove unnecessary temp variable in converting to UTF-8

These areas of code included a temporary that is unnecessary.
Fix some EBCDIC problems

These spots have native code points, so should be using the macros for
native code points, instead of Unicode ones.
mktables: Generate native code-point tables

The output tables for mktables are now in the platform's native
character set.  This means there is no change for ASCII platforms, but
is a change for EBCDIC ones.

Since we currently don't have any EBCDIC test platforms, I tested this
by faking it out to generate EBCDIC data, and then eye-balled the
results.

Code that didn't realize there was a potential difference between EBCDIC
and non-EBCDIC platforms will now start to work; code that tried to do
the right thing under these circumstances will no longer work.  Fixing
that comes in later commits.
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 converstion 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; this hasn't 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