fix(swingset): initializeKindHandleKind early enough to support durables

[warner]

Previously, kindIDID (the ID of the virtual object Kind that is used
to hold the KindHandles we need for durable kinds) was allocated
on-demand, the first time makeKindHandle() was called. The ID it
received (and the ID of everything allocate afterwards) thus depended
upon if/when userspace decided to use makeKindHandle().

In addition, vrm.registerKind() for the KindHandle kind was not
called until kindIDID itself was allocated. This doesn't necessarily
happen at all in the version-2 of a vat (i.e. if v2 doesn't define any
additional durable kinds), and can't be relied upon to happen before
v2 needs to deserialize the KindHandles that live in the 'baggage'.

So this commit changes liveslots to factor out the initialization and
registration into a new initializeKindHandleKind function, and
arranges to call it during startVat(). Several "fake" test harnesses
in tools/ were updated to call it as they build their stuff.

Many unit tests were updated to deal with the change in allocated IDs,
but they ought to be somewhat more stable now. Two of these updates
puzzled me:

• In test-gc-kernel.js, I understand why doomedExport1Vref changed
  from o+9 to o+10, and I'm not surprised that doomedExport2Vref is
  now o+11, but I don't understand why doomedExport2Vref was o+9
  before instead of o+10.
• In test-virtualObjectGC.js line 1297, why did the single- and
  multi- facet test cases start behaving the same way? Why were
  they different before?

refs #1848

[FUDCo]

One minor possible typo. Otherwise, seems legit.

[FUDCo]

Oh, I mixed up this PR with another one. Which is to say, the review above is a real review & assessment, but I haven't looked into the mysterious test changes yet.

[warner]

@FUDCo figured out the first of the two questions I had: the N-1 version of test-gc-kernel.js was relying upon an edge effect of the lazy sort I was doing. I was sorting the exported vrefs lexicographically, assuming they were all single digits and thus also sorted numerically. That was fine for the N-2 version (where the values were o+1 and o+2), but the N-1 version made them o+9 and o+10, which fell into the bug gap, and the test was updated to expect o+9 even though o+10 was what it should have been looking for. Then the most recent version became o+10 and o+11, and now o+11 is the right thing to look for.

I'll add a proper numerical sort to that test.

[FUDCo]

I think I figured out the second weird test difference. It's driven by the same root cause (different vrefs being generated and then sorted) but via completely different paths. In the previous version of the code the difference between the single- and multi-facet tests had to do with the order of operations -- basically, when in the sequence of things the various VOs got scanned for possibly being dead. This order, however, is sensitive to the vref strings themselves. The list of vrefs that possibleVirtualObjectDeath scans is sorted before scanning to ensure that the order of processing of the list is insensitive to what order the garbage collector scavenged the objects. Unlike the other test where sorting was implicated, in this case we don't actually care where in the list something is, we just want to ensure that the order is the same from one run to the next. However, the test itself is sensitive to the actual order because the test is actually looking for particular vrefs in a particular order. Before your change it was scanning o+10 (faceted thing) followed by o+11 (holder) in the faceted case, and o+11 (holder) followed by o+9 (unfaceted thing) in the unfaceted case. Hence the difference in the order to inspection of the .rc. keys between the two cases. In the new version it's scanning o+11 (faceted thing) followed by o+12 (holder) in the faceted case, and o+10 (unfaceted thing) followed by o+12 (holder) in the unfaceted case. In the new world order, in both cases the thing precedes the holder and the conditional logic is no longer needed. In this case there's no additional correction needed to the test (beyond what you already did), since the difference is in the actual underlying behavior of the vom.