Wide string status

[Mike Gran]

Hi-

It seems that the current push of the string_abstraction2 branch works
fairly well with respect to non-REPL code.  For examples of its basic
capabilities, see the encoding tests in the test suite, such as
test-suite/tests/encoding-utf8.test.

So, ports have two new properties: a character encoding, and a strategy
for dealing with characters unrepresentable in that encoding.
set-port-encoding! and set-port-conversion-strategy! are the big
procedures there.

I merged master into it to bring the branch up to date.

A source code file that contains non-ASCII chars needs to contain a
declaration like "coding: UTF-8" within a scheme comment in the first
couple of lines to be interpreted correctly.  UTF-16, EBCDIC and other
encodings that don't allow raw ASCII to be encoded unmodified are not
supported in the reader for source code.  (They sort of work for port
i/o but need more testing.)

Next, I suppose, is to get the compiler and REPL up and working.  That
requires chars be at least 21-bits wide in, for example,
language/assembly/compile-bytecode.scm.  I'm a bit intimidated by that
code, but, we'll see.

Beyond that, character sets need to be more than 256 chars, and readline
needs to be checked.  That would do for a release, I think.  Longer
term, R6RS ports need transcoders and then can be used to replace legacy
Guile ports as they become more feature complete.

I'm likely going to miss this point release, since I'm off on vacation
in a couple of days and shall not be thinking about code for a week or
two.

Late,
Mike