feat(swingset): Add Node.js Worker (thread) -based VatManager

[warner]

This adds a per-vat option to run the vat code in a separate thread, sharing
the process with the main (kernel) thread, sending VatDelivery and VatSyscall
objects over the postMessage channel. This isn't particularly useful by
itself, but it establishes the protocol for running vats in a
separate process, possibly written in a different language or using a
different JS engine (like XS, in #1299).

This 'nodeWorker' managertype has several limitations. The shallow ones are:

• vatPowers is missing transformTildot, which shouldn't be hard to add
• vatPowers.testLog is missing, only used for unit tests so we can probably
  live without it
• vatPowers is missing makeGetMeter/transformMetering (and will probably
  never get them, since they're only used for within-vat metering and we're
  trying to get rid of that)
• metering is not implemented at all
• delivery transcripts (and replay) are not yet implemented

Metering shouldn't be too hard to add, although we'll probably make it an
option, to avoid paying the instrumented-globals penalty when we aren't using
it. We also need to add proper control over vat termination (via meter
exhaustion or manually).

The deeper limitation is that nodeWorkers cannot block to wait for a
syscall (like callNow), so they cannot invoke devices.

refs #1127
closes #1384

[FUDCo]

This looks mostly fine so I'm approving it, but I'm a little concerned about having Node-specific stuff find its way into the kernel. I understand this is in service of the ultimate goal of pulling host-specific things into separable pieces with their own APIs, so we can do things like support XS too, but in the meantime I'm wondering if it's a good idea to have all this in one package. I suspect this is one of those "we'll know where to draw the cut lines once we have a couple of disparate examples to look at" things, so having it all in SwingSet is probably OK for now, but figuring out how to factor out the host-specific bits should be explicitly on our roadmap.

[warner]

Yeah. On one hand, the kernel shouldn't know much about the platform, and should get its authorities to launch new workers (whether they're in shared-thread Compartments, separate threads, or separate processes) from the controller. On the other, the kernel is speaking one half of a protocol that must be matched by the worker half, and putting both sides of that protocol in the same directory is the best way to keep them aligned (and the controller shouldn't have to know the details of that protocol).

We should also consider the code that is used by the worker: liveslots, and a couple of non-kernel-specific libraries, including the waitForQuiescent function. It's a bit weird to have liveslots nominally live in the kernel but only actually get used by workers. For the main-thread ("local") worker, it makes sense to give the worker a shared function reference rather than incorporating liveSlots.js into every vat bundle, but it means liveslots sits on this border between kernel and worker in a weird way. The answer might be to move liveslots out to a separate package.