Use separate macros for byte vs uv Unicode

This removes a macro not yet even in a development release, and splits
its calls into two classes: those where the input is a byte; and those
where it can be any unsigned integer.  The byte implementation avoids a
function call on EBCDIC platforms.
regcomp.c: Use Perl_form() instead of buggy sprintf

Commit 4cabb89a737018190d4e09360a6615e19160709f introduced tests
which include trying to look up a Unicode property whose name
is an upper Latin-range character.  This caused errors and a segfault
on some but not all patforms.  It also turns out that the error is in
some locales but not others.

The problem was there all along, and this commit merely exposed it; and
the bug is in the libc sprintf() for those platforms, which was used
to create the look-up property name.  This version of sprintf() turns
out to be locale-sensitive, and in a UTF-8 locale, it refuses to format
a %s that isn't valid UTF-8.  My guess is that sprintf and printf share
implementation, and such sensitivity may be warranted for printf, but
certainly not for sprintf.  It is undocumented behavior.  And it is
incorrect UTF-8 handling even if one were to output UTF-8 only.  The
reason for that is any malformed text should be turned into the
REPLACEMENT CHARACTER, not just skipped over.  This is a potential
security hole in in this sprintf() version.

The solution I ended up for Perl is to replace the sprintf() with
Perl_form().  I also looked at my_strlcpy() and friends.  Neither one is
as convenient as the buggy sprintf.  Feel free to replace this with
something better.