Buffer vat outputs to make cranks transactional

[FUDCo]

In order for the data stored by different kernels linked by a network connection to reflect a model of the world that is mutually consistent (part of issue #621), we need to ensure that the visible side effects of a vat processing a message are the same for all observers. One piece of this is making sure that no side effects persist in the wake of a failed crank, since in some cases a crank may be retried and could produce additional or different side effects as a result (for example, this could cause redundant message transmissions). In other words, we want cranks to be transactional. Liveslots already ensures this with respect to vat storage, but currently we do not do the same for vat outputs (i.e., transmitted messages and promise resolution notifications). Instead, the syscalls that produce these outputs are processed immediately, placing items directly into the kernel's (persistent) run queue to be delivered to other vats or to other kernels. The fix for this is to hold vat outputs until crank completion, then persist them as an atomic group on success or discard them on failure. This transaction crank behavior is also a pre-requisite for enabling vats to execute concurrently with the kernel or other vats (issue #334) and is a key required element for fully realizing output-valid rollback recovery (i.e., the Ken protocol; see, for example, HP Labs tech report 2010-155 or Terence Kelly et al's Usenix paper), a property we very much desire for the distributed ecosystem of communicating kernels.

These outputs could either be buffered by the kernel and persisted upon successful crank completion, or they could be buffered inside the vat that produces them and delivered in a bundle as an additional component of the crank completion record. This issue takes no strong position on which architecture is preferable, other than to observe that buffering in the kernel is probably less disruptive to the current implementation whereas buffering in the vats seems like it potentially could be more congenial to the world of independently executing vats.