Allow for only iterating over the most 'fresh' jobs

Instead of allowing the backend to determine how fresh
are the jobs yielded back (in the zookeeper case the jobs
are async populated so freshness depends on the freshness of
the watches established) allow the iteration method to support
a way to request (if backend supported) that the jobs iterated
be as fresh as possible.

Change-Id: I8a7c9d7d086ad5fa85dc842fb36e3356f781f057
Be better at failure tolerance

Instead of raising exceptions from a graph action
while tasks are still running or if a set of tasks
was scheduled and the last task could not be
scheduled (for example) just add the failure to the
failure list and continue processing what is actively
running.

This ensures that we don't leave futures in an
abandoned state and clean up our executing work which
is what all good behaving software should try to do.

Change-Id: I9256d7afa86f922273586a98b27442b6ba87767c
Add a directed graph type (new types module)

Most of the utility graph functions we have can
be connected to a directed graph class that itself
derives (and adds on to) the networkx base class.

Doing this allows for functionality that isn't exposed
in networkx to be exposed in our subclass (which is a
useful pattern to have).

It also makes it possible (if ever needed) to replace
the networkx usage in taskflow with something else if
this ever becomes a major request.

Change-Id: I0a825d5637236d7b5dbdbda0d426adb0183d5ba3
Merge "Add a directed graph type (new types module)"
Merge "Allow for only iterating over the most 'fresh' jobs"
Merge "Be better at failure tolerance"