The infamous "Pure PUTPROP Twice" bug

[RLB at MIT-MC (Richard L. Bryan)]

JONL and I just found why this one happens.

The symptoms:
   You push your property name P onto PUTPROP, hoping that
while loading up your system, putprops under P will be PURCOPYed, hence
sharable among users of your system.  While loading, symbol S gets 
a P property, and later gets another.  After purify/suspend/restart,
you find that symbol S has randomness under its P property -- randomness
which changes from GC to GC.

The diagnosis:
   PUTPROP is buggy.  The first time it tries to put a P on S, it finds
that there is no P there.  It checks for P memq in PUTPROP, finds it so,
purcopies the property value, purconses cells to go in the plist of S, 
and splices into the plist.
   The second time, PUTPROP finds P is on S.  It DOES NOT check for P
on PUTPROP, DOES NOT purcopy the property value, merely HRRMing it
into the plist cell.  The plist cell is typed in ST as needing to
become pure, but of course won't actually become read-only until PURIFY
runs.  Now we have the screw of impure sexp pointed to only by
not-marked-from pure sexp.  It will get collected (and its cells later 
reused) next gc.

The Rx:
    PUTPROP should check P for memq in PUTPROP and purcopy the value,
if necessary, in all cases.  It will need to remember if purcopying
took place so it will know to purcons new plist cells if it finds
that they are needed.

Notes:
(1) This is entirely unrelated to write-in-pure-page trapping of attempts
    by putprop to alter existing pure plist cells.
(2) Surgery on PUTPROP has not been performed.