Just directly use the built machine in the action engine and
avoid having another layer of abstraction that does not provide
that much value. This makes the code cleaner, and more easy to
understand (and so-on).

Change-Id: Iae1279098112254338258c1941c15889f1ad1a79

To make it easily possible to change the retry
atom execution from being in the engine thread this
creates a retry executor (which is similar to the task
executor) and provide that a serial executor (which it will
use to execute with). This makes the retry and task actions
closer to being the same and makes the surrounding code that
much similar (which makes understanding it easier).

Change-Id: I993e938280df3bd97f8076293183ef21989e2dba

Instead of having our own inbuilt fsm and table library
used to print the fsm states just use the newly created
and released automaton that contains the same/similar
code but as a released library that others can use and
benefit from.

Library @ http://pypi.python.org/pypi/automaton

Change-Id: I1ca40a0805e704fbb37b0106c1831a7e45c6ad68

When a atom is reverted it can be useful to retain the
result of that 'revert' method being called, so that it
can be later analyzed (or used for various purposes) so
adjust the storage, and actions to enable it to be stored.

Change-Id: I38a9a5f3bf7550e924468bb4a86652cb8beb306c

Split the states that are not task states (but are retry
states) into there own additional set and then use that set
and a new function to validate the transition at other locations
in the code-base.

This makes the transitions that are valid for tasks/retries
easily viewable, more easy to read and understand, and
more correct (instead of being a mix of task + retry atom
transitions and states).

Change-Id: I9515c19daf59a21e581f51e757ece2050f348214

There is really no need to seperate off the runner into
a unit that builds a state-machine and then provides a tiny
utility function, both of these can just be in the same class
and code so that it is easier to understand/read.

Change-Id: I18b97514e230451ef804a878a0edcea4d0b2ad20

Instead of having a nominally useful single-threaded storage
unit that uses a dummy r/w lock and a multi-threaded storage
unit just have the storage unit by default protect itself from
multi-threading calls being used on it (with the appropriate
reader/writer locks being activated to make this work
correctly).

Change-Id: Ib6879edb465156a8e54fd5b4002550d1cec49137

Internally we should be using the new location and not the
deprecated location wherever possible. This avoids emitting
warnings messages on our own code, which is a dirty habit.

Change-Id: Icc389e61613bc78e64083f0086f6f23aabd243d1