always rebuild protocol
implement new process running/attaching API

This replaces the Spawn, Link, Run, and Stream pattern, and renames Job to
Process.

Spawn, Link, and Stream are gone, Run is reinvented, and Attach is introduced.

The main problem with Link and Run is that they collect the full output in
memory. This is a risky pattern to expose as it could lead to excessive memory
usage when given user-provided code. The original Warden server enforced a 10MB
limit.

Another problem with Spawn and Stream/Link is that if the given script is
spawned and quickly exits before Stream/Link can attach, the client will
entirely miss the output, exit status, etc. Which is often exactly what you
want to see if something quickly barfs.

We initially started by adding an atomic "spawn and stream" brother to Run, but
given the existing problems with the other calls, we thought it better to
design a new API that we'd rather use. This is totally backwards incompatible.

The new API:

    Run: given a script, create a process, immediately return the Process ID,
         and execute the script and immediately start streaming output back.

    Attach: given a Process ID, re-attach to it and start streaming the output.

If the process is already active and its output is being streamed by Garden to
someone, this means the newly attaching client will miss a window of output.
However, if Garden is not attached to the process in any way, it's up to
iomux-spawn's ring buffer (currently 64k). This means that when Garden goes
down and comes back up, when the client reattaches it won't miss any output,
provided the process didn't exceed the ring buffer.

Run and Attach's output is exactly the same (a ProcessPayload). Later they may
be extended to accept stdin with the same payload message, being sent from the
client.

[#63917810]