Add APIs for tracking/debugging undesired object retention (aka "leaks")

[FUDCo]

Closes #7318

Adds two and a half API features to aid debugging and testing for leaks of objects managed by LiveSlots:

• The testHooks object returned by liveslots now contains a function getRetentionStats() that will return a data object containing the counts of the various non-singular objects that LiveSlots tracks internally. (LiveSlots keeps track of all these things in JavaScript Maps and Sets, so counting these objects is simply a matter of returning the sizes of these various collections. One consequence of this is that a getRetentionStats call will execute quickly regardless of how much stuff LiveSlots is holding onto.)

• The testHooks object now also contains references to all these various Maps and Sets directly. Note that this is powerful and dangerous, but it's confined to the testHooks object which is only exposed during testing.

• The data record that getRetentionStats produces is also returned as the result of every bringOutYourDead operation. From there it can be examined in tests, but, more signficantly, it will be output as part of the delivery status array that is written to the slog, so that a graph of object retention stats over time can be produced from a running chain or a long running performance test executing with a live swingset.

Collections passed in testHooks and counted by getRetentionStats:

Collection	Type	What
exportedRemotables	B	exported objects, to pin remotables; dropped on export drop
importedDevices	B	imported devices, to pin devices; grows monotonically
remotableRefCounts	B	objects referenced from off vat (from kernel or storage)
kernelRecognizableRemotables	C	exports recognizable by kernel
exportedVPIDs	C	promises exported; drop on resolve (vat is decider)
importedVPIDs	C	promises imported; drop on resolve (kernel is decider)
vrefRecognizers	C	vrefs used as keys in VirtualObjectAwareWeakMap/Set
definedDurableKinds	D	durable kinds that exist
kindInfoTable	D	info about kinds (durable + non-durable)
nextInstanceIDs	D	next id to allocate for kind once allocation has started
possiblyDeadSet	E	baseRefs to investigate for GC; cleared on BOYD
possiblyRetiredSet	E	vrefs to investigate for retirement; cleared on BOYD
slotToVal	F	live objects with vrefs
valToSlot	E	live objects with vrefs

Types:
A - Keyed by strings referring to virtual/durable store collections; cardinality is the total number of such stores
B - Keyed by direct references to explicitly in-memory objects; cardinality limited by RAM capacity
C - Keyed by strings referring to explicitly in-memory objects; cardinality limited by RAM capacity
D - Keyed by kindID strings; cardinality is number of defined knids (sometimes only durable kinds)
E - Transient collections, held weakly. Note that because they are weak collections they're not countable, so they lack corresponding counts in the retention stats
F - Keyed by vref strings referring to any kind of object currently addressable in memory

[warner]

looks good, small changes recommended