Add modules to define a working workflow.

Workflows are defined by subclassing simpleflow.Workflow. The dataflow
relies on simpleflow.futures.Future and the helper methods:

- futures.wait()
- Workflow.map()
- Workflow.starmap()

One can check if a computation is finished in a non-blocking way with
the Future.finished property.

See tests/test_dataflow.py for examples.
Add command line tool to run a workflow in local execution mode
Update local.executor: add logging in .submit()
Update activity: put full module in name
Update task: add Registry class and global instance registry
Update activity: register each Activity in task.registry
Add tests.test_task with basic test for activity registration
Update task.Registry: map a name to the corresponding task
Update README: describes main features and quickstart
Update Executor.submit(): handle TypeError exceptions of issubclass() and isinstance()
Update Workflow: put definition in .run() method insteand of __call__()
Add method swf.Executor.fail()
Update Workflow.fail(): use Executor.fail()
Update Executor: add private attribute _workflow and actual .run_workflow() method
Update Workflow: add abstract method .on_failure()
Update swf.Executor: call .on_failure() when the workflow fails
Update Executor: add abstract methods .on_failure() and .fail()
Update tests: check on_failure callback on each failed workflow
Update executor: more generic abstract interface

The interface was leaking part of the swf backend implementation. These
changes shrink the abstract interface to:

- .submit()
- .run()

.replay() was renamed in .run() because it enforces a specific semantic.

Methods related to the swf backend and its replay semantics were moved
to `swf.executor.Executor`.