encodings removed

Encoding support was a bad idea because it introduced an ever-escalating
amount of complexity for little to no benefit.  Encodings were intended
to allow color-arrays to address directly into pixel buffers, however it
quickly became apparent that whatever gain in efficiency for that case,
a greater loss of efficiency was incurred in every other case because
color values have to be type-checked at every step, accessors, setters,
and other procedures must be looked up, and type-specific optimized
procedures must be written for different encodings.  Not only does the
complexity within the library escalate, but it spills out to programs
that use it, too.  It also became apparent that there are really very
few use cases for dealing with non-normalized color values in practical
color-manipulation code, so it makes more sense to move to a design
where we are doing a conversion when we bring values into the library,
and another conversion when we take values out, but use normalized
values uniformly for all manipulations while in it.

We have chosen to use srfi-4 f64vector as the internal storage type for
color data instead of scheme vectors.  It has the advantage of being
easier to write optimized foreign code for when need arises.