1.0.7.2: fix potential GC errors due to bogus objects in backtraces

1.0.7.2: fix potential GC errors due to bogus objects in backtraces

 Backtrace construction involves calling MAKE-LISP-OBJ on things we
 devoutly hope are tagged lisp pointers, but this is not always the
 case. When we fail to detect this, and a GC follows while the bogus
 object is at location visible to GC bad things will happen. (Pinning
 doesn't change anything, as the object still needs to be scavenged.)

 To fix this (mostly -- one can still construct bogus lisp-objects
 using MAKE-LISP-OBJ, it just takes more work / is less likely to
 happen by accident):

  * Rename MAKE-LISP-OBJ %MAKE-LISP-OBJ, and MAKE-VALID-LISP-OBJ
    MAKE-LISP-OBJ.

  * Add an optional ERRORP argument to the former MAKE-VALID-LISP-OBJ,
    defaulting to T.

  * Always use the function formerly known as MAKE-VALID-LISP-OBJ,
    passing in errorp=NIL when in doubt.

  * Improve the validation done on x86/x86-64: factor out the checking
    logic in possibly_valid_dynamic_space_pointer, and use it to
    implment valid_lisp_ponter_p. Could be done on other platforms as
    well, but better done by someone who can test the results...

 Adjust other code to suit:

  * MAP-ALLOCATED-OBJECTS uses %MAKE-LISP-OBJ for now, as the new
    MAKE-LISP-OBJ is too slow to use for groveling over the whole
    heap. (Though it does detect a bunch of bogus objects we're
    constructing in ROOM now, so the time would not be really
    wasted...)

 No test cases because I've been unable to construct one that calls
 MAKE-LISP-OBJ with bogus arguments while backtracing, but such
 backtraces have been seen in the wild.