feat: rewrite delivery-result processing, rewind failed upgrades

This commit modifies vat-upgrade to respond correctly to failures
during the upgrade process, by rewinding the vat back to it's
pre-upgrade state.

If a failure occurs either during the `stopVat` sent to the old
version, or during the `startVat` sent to the new version, the
consequences of both deliveries will be unwound, the 'upgrade-vat'
event popped from the delivery queue, and the worker abandoned. The
next delivery to this vat will cause a new worker to be created from
the previous state. The only state change that survives is a message
to vat-admin, instructing it to reject the
`E(adminFacet).upgradeVat()` result promise.

From the outside world, it will appear as if upgrade was never
requested, except that `upgradeVat()` rejects.

To implement this, I rewrote the way delivery results are handled in
kernel.js . `deliverAndLogToVat()` still returns `DeliveryStatus`, but
each `processXYZ` function (`processSend`, `processVatUpgrade`, etc)
is now responsible for transforming that `DeliveryStatus` into a new
`CrankResult`. This `CrankResult` tells `processDeliveryMessage` what
to do in a uniform way: abort the crankbuffer changes, terminate a
vat, deduct a meter, etc.

Most processor functions use a shared `deliveryCrankResults` helper
function to build their results, which takes flags to indicate whether
the delivery should deduct a meter, should decrement the
BOYD/reapCount counter, etc.

`processCreateVat` does its conversion in a different way, to merge
the results of the two deliveries (`stopVat`, `startVat`), and to
abandon the process in the middle if `stopVat` failed.

This will also make it trivial to begin charging a meter for the work
done during `startVat`, and to report this work to the
runPolicy. However it does not do so yet.

closes #5344