feat: Implement persistent storage for vats.

[FUDCo]

This PR implements a persistent storage mechanism for vats, per the design described in issue #431.

The kernel storage has been augmented with a new table that holds data for vats. This involved some fairly extensive refactoring of the kernel storage API, but I think clears up a few things that were previously a bit confused and so I think it's a net improvement in its own right.

The initVat command from the Kernel to the VatSupervisor now carries an initialization parameter that the VatSupervisor will use to initialize its in-memory cache of the vat's persistent state as it existed prior to the vat process being created (of course, for a new vat this will be empty).

The responses to the initVat and deliver vat commands returned to the Kernel from the VatSupervisor now carry deltas to any persistent data changes that were made during the execution of the crank. The kernel will record any such changes in the relevant vat's vatstore in the database.

Important Note: this feature gives us all the machinery necessary to restart a vat and resume its operation after the extension has been reloaded (either due to an explicit extension reload or due to browser restart). However, the kernel startup logic does not yet make use if this, so if you reload the extension you'll just get new vats rather than getting the old vats back again. This is another task that needs to be done, see #437.

Closes #431.

[sirtimid]

LGTM!