Add FAST-NEGATE/UNSIGNED VOP to x86 and ARM.

Same as the x86-64 change.
Optimize (LOGIOR SIGNED UNSIGNED) on x86 and ARM.

Add two VOPs for combinations of unsigned-num and signed-num
arguments.
Handle additional generalized places in ATOMIC-{INCF,DECF}
Don't warn about everything from 'setf-funs' in the cross-compiler
Combine the special-form-constantp hash-tables into one.
Get rid of a bunch of useless gensyms from the image
Make specialized vector treatment in cross-compilation more consistent.

There were a few ways of dealing with the issue that ARRAY-ELEMENT-TYPE
could accidentally reflect the host's array type:

(A) carefully writing a form to reconstruct a constant in the target
    as exemplified by COMPUTE-TEMPORARIES-DESCRIPTION in meta-vmdef,
(B) taking :ELEMENT-TYPE as merely a suggestion,
    like in EMIT-LONG-NOP in compiler/x86-64/insts,
(C) not caring, even though it could in fact generate broken fasls
    if the host upgraded (UNSIGNED-BYTE 8) to anything else, such as
    **CHARACTER-DATABASE** which directly assigned a compile-time
    constant into a variable having a specific type proclamation.

This change makes the cross-compiler warn of a potential problem when
writing out a constant array. e.g. The Unicode database was technically
incorrect but not ostensibly broken, because every supported xc host
provides (UNSIGNED-BYTE 8) as a specialized array type.
Nonetheless, we tried to be rigorous most of the time, which led one
to question why/when care had to be exercised.

So now it is an error in the crosss-compiler to dump a numeric array
other than BIT unless it has been "registered" with its precise type;
but (UNSIGNED-BYTE 8) emits only a style-warning if unregistered.

Note that case (B) wasn't visibly broken, but different host Lisps could
produce different target code. A read-time constant array might be upgraded
to any type of which (UNSIGNED-BYTE 8) is a subtype, but compiled AREF
would be ok because CTYPE-OF as defined in 'cross-type' reflects whatever
the host thinks, and AREF would emit correct code to match that
as long as there were no local type declarations to the contrary.
Clean up *.exe files from tools-for-build/

Otherwise building different architectures from the same source tree
is problematic on Windows.
Fix typo in compiler note in SB-PCL:CAN-OPTIMIZE-ACCESS
Don't transpose sole constants within arithmetic functions.

There's no performance improvement in transforming (* x y 100) to (*
100 x y), except for possible FP precision loss.
Reduce +constants+ for arithmetic functions.

Reduce defconstant constants, i.e.,
(+ x +a+ +b+) to (+ sum-of-a-and-b x).

Closes lp#1337069.
Remove duplicate invalid-superclass handling in SHARED-INITIALIZE :AFTER STD-CLASS

* In fe027d69, a new condition and a generic function, both named
  INVALID-SUPERCLASS, have been introduced. As
  expected, (SHARED-INITIALIZE :AFTER STD-CLASS) delegates signaling the
  invalid-superclass problem to INVALID-SUPERCLASS.

* However, in fe027d69, the previous code for "directly" signaling a
  SIMPLE-ERROR remained in (SHARED-INITIALIZE :AFTER STD-CLASS),
  probably by mistake.

* This commit removes the redundant code and slightly tweaks the report
  of the INVALID-SUPERCLASS condition.
restore clisp buildability

fixes lp#1331141; thanks to Vasily Postnikov
really fix clisp build

Thanks again to Vasily Postnicov
Avoid calling SEQUENCEP in the XEP for some seq-dispatching functions.
Remove 15K lines of useless noise, revealing the interesting noise
Fix GNU/kFreeBSD x86-64 and add x86 support.

The x86-64 patch wasn't fully merged and couldn't be built.
x86 needed a similar simple replacement __FreeBSD__ => LISP_FEATURE_FREEBSD.

Also add :gnu-kfreebsd feature for easier differentiation.
Refactor SEQUENCEP and EXTENDED-SEQUENCE-P
Minor tweak to instance TYPEP transforms.

After (SETQ <x> (UPDATE-OBJECT-LAYOUT-OR-INVALID))
it is not known that <x> is a LAYOUT. But the call either
signals an error or uses CHECK-WRAPPER-VALIDITY
which *must* return a wrapper (a layout).
Refactor INTERN and FIND-SYMBOL.

Avoid or delay copying to a simple-string when given a string
with fill-pointer as the input.

Fix a bug that one of the string.pure tests succeeded for the wrong
reason: (INTERN (MAKE-ARRAY 0 :ELEMENT-TYPE NIL)) reached an unhandled
case of STRING-DISPATCH, but a previous call to (INTERN "") hid it.