ActionProcessors in place of WorkflowActor

the `WorkflowActor` mixin was not convenient
to work on because the code execution flow
was tangled. e.g.:

`publish` -> `take_action` -> `record_action`
-> `Edition#new_action`

every action was being routed through this
method call chain because they had common
behaviour:

* check certain pre-condition to determine
whether to carry-out the state transition
* process the action parameters, or event
parameters before the state transtion
* carry-out the state transition
* record that this transition was done,
conditionally in some cases
* conditionally return a result

now the common behaviour has been modelled
as a `ActionProcessor::BaseProcessor` and
any special cases can be handled within
individual `ActionProcessor` classes by
overriding certain methods.

as a result the `WorkflowActor` is gone.

some of those methods have intentionally
been kept in the `User` class, so that
they force us to re-think when we're
bloating the `User` object. these methods
simply delegate action processing.

test helpers have been added to ensure
that we test the workflow in the same
way as we use it. Publisher, is where
most workflow actions are triggered,
and it uses `EditionProgressor` which
calls the `User#progress`. that's how
we should test the workflow, instead of
directly calling helper methods, which
existed earlier.

some tests in `Publisher` have been
updated to use these test helpers.

`WorkflowActor` tests have moved to
`Workflow` test, because they belong
there.
Extract actions behaviour from Workflow

though actions are related to Workflow
in a way, we can keep those methods in
a seperate file for clarity.