Refactor logic for tracking workflow progress out of WorkflowInvoker.

Creates a new class WorkflowProgress. This has class achives two objectives:

- I am trying to move specialized per-module-type logic out of WorkflowInvoker and into the modules themselves - making it easier to add new modules and because it is better OOP design (invoker shouldn't be dispatching on .type - the modules should provide a consistent interface for invoking themselves). WorkflowProgress will give something that WorkflowInvoker can pass along to the modules to allow them to find their connections and record their outputs.

- Downstream in workflow scheduling branch I am placing logic in here for rebuilding the in-memory state of the workflow progress when re-evaluating progress.
Unify WorkflowModule execute method.

Previously tool module class did not contain this method (though it was described as abstract in the base class) and extra logic for dealing with tools was located outside of the module class. Moving everything into the module (made possible by previously committed WorkflowProgress class and attaching some properties to workflow invocations and sending them in) means that now the worklfow invocation logic can uniformly deal with modules and doesn't need to dispatch on type.
API functional test for workflow 'replacement_params' and PJA renaming.