implement dispatch.retireExports for Remotables

[warner]

fix(swingset): implement dispatch.retireExports for Remotables

This updates liveslots to implement kernel-delivered
dispatch.retireExports, but only when the object being retired is a
Remotable (virtual objects are left alone for now).

Retiring an exported Remotable means we remove it from the slotToVal and
valToSlot tables, and unregister it from the droppedRegistry. At this
point, vat code might still hold a strong reference to the Remoteable, but
liveslots is unaware of it. If the vat re-exports the object, it will get a
new vref.

This also comments out some debug messages.

refs #3106

[FUDCo]

I'm unclear why virtual objects should be treated specially in this case. Is it related to the fact that virtual objects can still point to things even while being swapped out? If so I can see why letting them just get swept might leave dangling garbage on disk, but that's a "what's the proper procedure to delete this?" problem, not a "should we delete this?" problem. Otherwise I don't see how they're different from any other Remotable. What am I not understanding?

[warner]

Virtual object GC is still pretty incomplete. dropExports effectively ignores them (Representatives are never put in exportedRemotables, and that's the only thing dropExports touches so far), so the virtualObjectManager is not yet being told that the kernel has given up reachability. retireExports is the kernel's way of giving up recognizability too, and we can't act upon that until we've first implemented the code that acts upon the drop.

The full flowchart for GC of virtual objects is the big one in #2724 (comment) . retireExports is one signal, but the algorithm must also keep track of any Representative and whether the vref is reachable from (and/or recognizable by) virtualized data. It isn't safe to forget the virtual object merely in response to retireExports.

When we're done, we'll definitely act upon dropExports and retireExports for virtual objects: ignoring them is a temporary measure until we build up more code to implement that large flowchart. But that's currently a minority use case (the only virtual objects we use so far are Purses, and they're relatively long-lived, at least compared to Payments and Offers and everything else that gets thrown around). And we do already have enough code to safely act upon it for Remotables, which ought to save us meaningful space now. So it's a phased-implementation approach.

My plan is to either build a separate "reachability manager" that manages that flowchart, or enhance the virtualObjectManager. At that point, retireOneExport will just do reachabilityManager.kernelRetired(vref) and let the other code figure out the consequences.

[FUDCo]

I think this is good to go.