add VatWorker for Node.js-based child process

[warner]

We're rearranging the way the swingset kernel interacts with vats. #1339 introduced a "Vat Manager", which provides a unified data-centric interface for all kinds of vats, where serializable VatDeliveryObject and VatSyscallObjects can be passed back and forth. It factored out all the kernel/vat translation code into a common layer, and defined a VatManager interface with a .deliver() method. Once the Vat Manager is created, the kernel only interacts with the manager. The manager then owns a "Vat Worker", which communicates exclusively with the manager and hosts the actual vat code.

#1366 will add a second kind of worker, which launches a new Node.js thread (the Worker object) to host the vat code, and then uses postMessage (and its "structured clone" mechanism) to send deliveries and syscalls over the thread boundary. The original approach is now known as a "local worker". When adding a vat, a new managerType option lets you choose between local and nodeWorker.

This ticket is about adding a third "node-process" type, which spawns a new child process to host the vat code. The delivery/syscall messages will be serialized to bytes, framed in netstrings, and sent over a pipe. The child process will do a blocking read from the parent, which allows us to stall the child while the kernel performs device invocations. This will allow the node-process worker to use device reads, which the node-thread worker cannot (unless/until we involve exotic tricks with Atomics and SharedArrayBuffer).

The child process will start from a supervisor file that lives in the swingset tree, just like the node-thread worker spawns a thread which starts from src/kernel/vatManager/nodeWorkerSupervisor.js. This supervisor program will import ses, liveslots and import-bundle. It starts by installing SES, then establishes the pipe-message handlers, then waits for instructions. The first instruction will be to load a bundle with import-bundle, then extract the buildRootObject method and use it to build a liveslots instance. Then subsequent instructions will contain deliveries to pass into liveslots, which dispatches them into the vat's objects. Syscalls are handled by sending requests back over the channel to the kernel.

The kernel side of the node-process worker will look nearly identical to @dckc 's #1299 xs-process worker: it uses the same serialization and messaging. The only difference should be the program that it launches.

[warner]

This exists now.