mostly make the build deterministic

From clisp, about 10 files still differ in xc fasls after these changes.
At least one remaining issue is obvious (floats, where our float constants
aren't representable on clisp) but there are other mysteries.
allow builds with :trace-file flags even with non-sbcl host compilers

:allow-other-keys t is a marvellous thing
slightly more reproducible builds

in vop templates, (:constant <type>) eventually boiled down to a TYPEP
test.  For (:constant fixnum) in the cross-compiler, this is not right,
because the typep test runs on the host.  Use SB!XC:TYPEP instead, which
means making sure that types are available to the cross-compiler (using
DEF!TYPE instead of DEFTYPE).  Tested on x86-64; one issue on ppc fixed
blindly.
one more stray GENSYM leading to fasl differences
sort *features*ish variable values for repeatability
remove world-lock from WITH-COMPILATION-UNIT

   Add it to SUB-COMPILE-FILE and ACTUALLY-COMPILE instead.
move clearing of *FREE-FUNS* &co to WITH-IR1-NAMESPACE where they're bound
bind and clear *SEEN-FUNS* and *SEEN-BLOCKS* in CHECK-IR1-CONSISTENCY
bind and clear *LIST-CONFLICTS-TABLE* in LIST-CONFLICTS
bind and clear *CONTINUATION-NUMBERS* &co in WITH-COMPILATION-VALUES

  This leaves CLEAR-STUFF empty, so delete it. \o/
more debug output for the once-in-a-blue-moon cache flushing problem

  ...was stupidly printing only 1/3rd of the intended amount of
  information. *sigh*
fix walker handling of LET* bindings shadowing symbol macros

  Don't remove variable bindings from lexenv, which would cause
  symbol-macros to be unshadowed.

  Also treat special bindings correctly -- this comes mostly down to
  processing declarations from the body before processing variable
  bindings.
update NEWS
PPC, SPARC cross-type build fix

Thanks to Christophe Rhodes.
SPARC gencgc

Based on Raymond Toy's work.
Allow use of SB-RT's mechanism for expected test failures in contribs

... In RT, use the list of expected test failures not just for
    debugging output, but return as a primary result only whether
    there are unexpected failures, with additional result values for
    details on expected failures.

... Tweak make-target-contrib.sh so that the `test-passed' file, if
    non-empty, can indicate a `successful' build of the contrib with
    only known failures.

This mechanism is meant to follow in the footsteps of SBCL's main
test suite's mechanism for known failures, and is arguably not in
the original spirit of contribs as user contributions that must
build perfectly or fail to install entirely.  However, for parts of
contrib/ which are very commonly used as a part of SBCL, it is hoped
that this new mechanism will aid work toward bug fixes in those
contribs rather than de-emphasize it.
Reenable ALLOCATION-INFORMATION.4, mark as known failure

It seems unlikely to me that the combination of features currently
identified as problematic is truly accurate.  More plausible seems
that ALLOCATION-INFORMATION is broken and needs a bug fix.  Yet the
warning now given should be clear enough and allow users to report
this issue.
Run sb-bsd-sockets tests on windows

Previously, we did not attempt tests for this contrib on Windows at
all, presumably because this (otherwise functional) contrib would
have failed some tests and hence would not have been installed.

Instead, mark the remaining failures as expected, so that they get
reported without preventing installation of the contrib.
Do not trash registers in tests/win32-stack-unwind.c
Port WITH-TLS-EA and other remaining FS prefix uses to Windows.

- current-thread-offset-sap

- emit-single-step-test

- Allocation routines

- Disable PSEUDO-ATOMIC on threaded Windows entirely instead of
  changing TLS uses of pseudo-atomic-bits.  We would need a
  temporary register for those changes, and Windows threading is all
  safepoint-based, without the need to support asynchronous signals.

Thanks to Dmitry Kalyanov and Anton Kovalenko.