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.
I was implementing a stupid simple task store framework side (IE: "within gozer").  In the real world, either a DB, or some replicated state/storage would take the place of this.  I'm basically protecting against the web/http side doing things at the same time the framework side may do something.

Note: this is not the task store for the mesos side.