liveslots+vatManager must provide secondary-storage API to vats as global

[warner]

What is the Problem Being Solved?

As described in #1846 (comment) , we're going to need to provide some secondary-storage "container" / Representative APIs to get handed to vats. The tricky part is that we want to provide them as globals, rather than as properties of the vatPowers argument we give to buildRootObject().

This is challenging because of the way vats are built:

• the vatManager prepares the set of globals to provide
• the vatManager uses importBundle to evaluate the vat code, returning the exported buildRootObject function
• the vatManager then calls makeLiveslots(buildRootObject), to get back thedispatch object which will handle deliveries

For this task, makeLiveslots is also creating the container APIs, because they must share the marshalling tables which liveslots manages (vatToSlot and friends). That's a problem, because we need these APIs to be available well before we call makeLiveslots.

So there's a cycle that needs breaking.

[warner]

proposal:

const { vatGlobals, dispatch, setBuildRootObject } = makeLiveslots(syscall, state, ..);
const ns = await importBundle(bundle, .. vatGlobals);
setBuildRootObject(ns.buildRootObject); // calls buildRootObject() once before returning
return dispatch;

It would be a "this should never happen" error for the kernel to invoke any dispatch methods before setBuildRootObject() has been called.

[warner]

Note that maybe vats should consume these global objects via a "ponyfill" package (@agoric/weak-store? @agoric/external-store?), so that unit test code can import from that package and work without actually running inside a vat.