Async state machine

The start of moving things into a state machine.  Still lots of work required.  In particular, there are some fundamental design decisions that need to be made:

 * Who owns the concept of a task?
    * gozer: then the coupling between gozer (and other go frameworks) will be rather tight to the protobufs and the internals
    * mesos: the mesos task is likely insufficient to encompass the full life-cycle given the next question

* What type of tasks gozer support and present?
    * one-shot
    * batch execution
    * scheduled/periodic execution
    * service based
    * other?

For all of these, I can think of a different Task state diagram, with the core likely being the same (as that is somewhat dictated by Mesos' task state diagram).  The one-shot is likely as basic as it get's, but even there you quickly run into concepts such as PENDING, ASSIGNED, etc.
Why change?  This endpoint is just for the interaction from the master to this framework.