1.0.5.34: faster STRING-TO-OCTETS for unibyte and UTF-8 encodings

1.0.5.34: faster STRING-TO-OCTETS for unibyte and UTF-8 encodings

	* redo DEFINE-UNIBYTE-MAPPER to use a lookup table instead of
	  a big CASE statement (optimizes for the common (?) case of
	  mostly ASCII characters and gives smaller code);
	* STRING->LATIN% now optimistically assumes that there are
	  no encoding errors in the string and allocates an
	  appropriately-sized octet vector upfront, falling back to
	  the slower path if an encoding error is detected;
	* do more or less the same thing for UTF-8 encoding, except
	  that there is no slow path (since UTF-8 can encode all
	  characters, unlike unibyte encodings)
	* we have a ton of external formats; use a hash table for
	  *EXTERNAL-FORMAT-FUNCTIONS* rather than a list to cut down
	  on lookup time (this alone is worth ~10% without the other
	  optimizations above...).

	Code cleanups:

	* use string package names like every other source file;
	* properly separate function names from arglists;
	* don't pass END parameters when we don't use them.

	End result is ~20-30x speedup for unibyte encodings (depending
        on the encoding--LATIN-1 is ~20x, whereas something like CP857
        is ~30x) when encoding ASCII strings; smaller but still
        significant speedups when encoding non-ASCII strings.  UTF-8
        encoding is ~5-6x faster, which also means that we're faster
        than TRIVIAL-UTF-8 for encoding now (decoding is an entirely
        different matter).