* 0.9.8.19 moved zeroing from GC time to allocation time, but after
the point where the check was done -- thus causing the check to
fail immediately if it was turned on. This commit moves the check
after the zeroing, so we're good again.

...which also means that gencgc_zero_check=1 is not very
interesting anymore, since the zeroing happens in the immediate
vicinity of the check.

* For negated EQL constaints, don't cons up multiple MEMBER-TYPE
instances during a single pass through CONSTRAIN-REF-TYPE:
accumulate a single XSET, and turn it into a MEMBER-TYPE only at
the end.

* Don't construct (NOT (MEMBER ...TON-OF-SYMBOLS...)) types at all,
unless SPEED > COMPILATION speed. Knowing that a variable is not
in a set of symbols is seldom useful, and compiling large CASE
statements with symbols as keys can end up spending huge amounts
of time just building these sets.

* Adjust FD-STREAMS to use an ECASE in the single place in SBCL where
without the aforementioned constraint propagation the compiler is
not able to determine sufficiently constrain the result type. (Not
needed since the build has SPEED > COMPILATION-SPEED, but keeps
things non-brittle.)

* Instead of searching for the external-format object to obtain
the character-width function, store the function (or its result
for fixed-width external formats) directly into the FD-STREAM
object. Non-FD-STREAM ANSI-STREAMS use the old strategy.

1.0.14.30: don't construct obsolete instances
The CTOR make-instance optimization machinery closes over the
class wrapper of the class in question; however, there are
code paths that cause wrappers to be invalidated without causing
all constructors to be recomputed: for instance, the
redefinition of a superclass, or calling
MAKE-INSTANCES-OBSOLETE. This would mean that the CTORs would
create obsolete instances, which would instantly trap, showing
up as slowness in CLOS-heavy code.

Problem and fix largely identified by Andy Hefner in
<http://paste.lisp.org/display/55689>.

* When lifting constants out of code in FGEN construction, leave
constant lists in place: several of the functions we generate FGENs
for have ETYPECASE forms, which will otherwise cause us to close
over the :EXPECTED-TYPE and :POSSIBILITIES arguments to ERROR for
no good reason.