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.
using a waitgroup here will be fine, rather than having a health endpoint that may change in the future.