Semantics of the routine readkey

The C kernel once left the bit "involvedw" on in a sense key as it was fetched into a general registers node. This was bad. It was first ascribed to a bug in routine jsense but I think other routines call readkey what whould not be expected to see an involved key as a result. readkey, in primcomc.c, needs a clearer contract. I will begin to accumulate such a contract at the end of this note.

In the case of a hook key, readkey returns the address of either DK(0) or DK(1). It seems reasonable for it to return a pointer to an uninvolved copy of the involved key. There is an issue of how long to keep this copy. There is also the issue of backchain maintanence which is sensitive to the addresses of keys. The address of the copy must not become part of a back chain.

We must thus poll readkey clients to see what they expect and what they need.
------------
Contract for readkey

"readkey" returns the address of the logical (yet prepared) version of the key located by the argument. readkey will take proper steps in case the key is involvedr, such as extracting the information from wherever is necessary. The resulting image will not be involved. (In some sense the returned pointer points to the logical key; the involved bits have to do with the slot holding the key, not the key!) While in common cases the returned location will be the same as the passed location, the back chain information in the image is not to be used as it may not reside in a node.

-------------
todo stack

jsense leaves the dr bit on even if the dw bit is off for a somewhat different reason. Changing readkey won't fix that! It might be fixed by calling readkey under additional circumstances.

Find out why readkey returns 0.
  Because superzap returns something other than unprnode_unprepared which presumably is because the key could not be uninvolved. Perhaps this is a case of not resorting to the slow-way.