fix: liveslots: initialize counters in startVat, not on-demand

[warner]

Liveslots maintains three counters: the Export ID (used for o+NN
exported object vrefs), the Promise ID (for p+NN allocated
promises), and the Collection ID (one per virtual/durable
collection).

Originally, these counters were only held in RAM: initialized during
makeLiveSlots() and incremented when needed. To fix #4730,
makeLiveSlots() was changed to read them from the DB, and then
liveslots writes them back to the DB at the end of any delivery which
modifies them. This ensures that a future version of the vat+liveslots
can pick up allocation where the previous version left off.

However the DB read to initialize the in-RAM copy did not set the
'dirty' flag. This caused variations in DB writes across different
vats: startVat would not write out the initial values if
buildRootObject did not happen to export any additional objects. In
addition, since the DB value is a simple JSON.stringify of the
counter record, the order of the keys varied depending upon whether an
Object or Promise or Collection ID got allocated first.

This commit changes the counter initialization process to use a fixed
order for the counter names, and to always perform the
initialization (and DB write) at the same time in all vats: during
startVat, with a write at the end of the delivery. This should make
the initial kvStore contents (just after startVat) more consistent.

The new initialization code should behave correctly when we add new
counters in the future: it will merge the new counter names (and
initial values) into the record it reads from the DB during startVat.

A handful of unit tests were updated to expect the new order.