Prevent sign extension of char in string pointer accessors

When string pointers on a single-byte string retrieve a char
and it has code between 0x80 and 0xff, it was treated as a signed
char and its sign is extended, resulting negative ScmChar value.

They aren't noticeable with native encodings other than 'none', since
on other encodings having that byte range in strings means it's
a multibyte string and the code path was never executed.
In 'none' native encoding, let ucs->char return subst char for invalid range

It is pretty inconvenient when literal character notation beyond
0xff throws an error when the native encoding is 'none'; even the
program uses cond-expand, the error occurs before macro expansion
(at read stage).  So we let the reader return a substititon char #\?
in such case.

This may allow subtle bugs to slip into the code if a programmer
isn't careful enough to use cond-expand.  We think it's acceptable
since encoding='none' is deemed to be gone by 1.0 release.
Adjust tests to cope with encoding='none'

Some tests can't be executed if encoding='none'.  Cond-expanded.
Fix Scm_ReadXdigitsFromString for non-utf8 encoding