move vatParameters to startVat() delivery

[warner]

fix(swingset): deliver vatParameters in startVat()

Previously, vatParameters arrived at a vat worker in the setBundle
message to the supervisor (the same one that provided the vat's source
bundle). This changes the code to deliver them inside the
dispatch.startVat() invocation instead.

Liveslots-based vats see no change: both cases hand vatParameters in via the
buildRootObject() call. setup()-based vats must change: the setup()
call no longer contains a vatParameters argument, and vatParameters are
available temporally later than before.

As a result, the comms vat must wait for startVat() to learn its two
configuration settings: identifierBase and sendExplicitSeqNums. Comms now
uses both to initialize its state DB, and reads sendExplicitSeqNums from
the DB for each transit() call.

This paves the way for vatParameters to contain slots, not just inert data.
The VatTranslator that converts startVat KernelDeliveryObjects into
VatDeliveryObjects does not yet perform slot translation, nor does liveslots
treat vatParameters as capdata, but they are now in the right place to
perform those tasks.

refs #4381
closes #4766

[warner]

@FUDCo I recommend reviewing one commit at a time, they're pretty independent, but the first two seemed too small for their own PRs.

[FUDCo]

Looks fine, though it seems like a lot of mechanism just to add one parameter to startVat.

[warner]

Looks fine, though it seems like a lot of mechanism just to add one parameter to startVat.

True, but the important thing is that startVat (as a delivery) can have its arguments translated through the c-list (and populates the c-list, and increments the refcounts), which means vatParameters will be able to hold slots, which means they'll be able to hold bundlecaps, which is important for our upgrade story.