introspection-based use of %instance-ref and type-checking

[Douglas Katzman]

Uses of %INSTANCE-REF and/or its raw slot variants generally disregard DSD-SAFE-P.
Conceivably we could strengthen some of these for SAFETY 3.
The places I see at first glance:
- COPY-STRUCTURE
- PSXHASH and EQUALP
- MAYBE-EMIT-MAKE-LOAD-FORMS, CONSTANT-FOPCOMPILABLE-P, DUMP-STRUCTURE
  (internal use, but essentially exposed via the observable behavior)
- DO-REFERENCED-OBJECT (internal, not terribly important)

Example:
(defstruct person id)
(defstruct (spy (:include person (id " " :type (simple-string 2)))) gadgetry)

(let ((s (make-spy :id "86" :gadgetry '(shoe-phone))))
  (setf (person-id s) "max")
  (copy-structure s))
=> #S(SPY :ID "max" :GADGETRY (SHOE-PHONE))
where we know that SPY-ID on the resultant object would fail.

So ostensibly COPY-STRUCTURE has both read and written the illegal value and did not signal an error in either case. It has been this way essentially forever.

Recent change https://sourceforge.net/p/sbcl/sbcl/ci/e971aa48 _removed_ checks in the optimized EQUALP which merely aligns it with the old behavior for the unoptimized EQUALP, which always operated by introspection. So the type-specific EQUALP "method" is faster but strictly equivalent, which I should have been more clear about rather than insinuating that it's a deficiency.

As to whether it should be an error to take an object that has been so constructed as the example above and insert it into an EQUALP hash-table, I can't see failing in (SETF GETHASH) as useful.
Is it mandated that it fail? We might never call EQUALP if no <k,v> matched on hash, and the hash function might not mix in the slot which is type-incorrect because of the depthoid cutoff.

I think though that MAYBE-EMIT-MAKE-LOAD-FORMS should complain about structures that ought not to have been constructable.