Clean up

#### removing `WorkflowActor`

the `WorkflowActor` mix-in was not convenient to work on because the code execution flow was tangled. e.g.:

`publish` -> `take_action` -> `can_<action>?` -> `Edition#<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 attributes, or event attributes before the state transition
* carry-out the state transition
* record that this transition was done, conditionally in some cases
* conditionally return a result

this flow was difficult to understand in the first place, and to debug.

the common behaviour has been modelled as `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 make it visible when we're bloating the `User` object, and force us to re-think. these methods simply delegate action processing.

#### test behaviour the same way as we consume it

[test helpers](https://github.com/alphagov/govuk_content_models/blob/clean-up/lib/govuk_content_models/test_helpers/action_processor_helpers.rb) have been added to ensure that we test workflow in the same way as we eventually consume it. Publisher is where most workflow actions are triggered, and it uses `EditionProgressor` which calls the [`User#progress`](https://github.com/alphagov/publisher/blob/master/lib/edition_progressor.rb#L23). so, that's how we should test the workflow, instead of directly calling wrapper methods, which are removed. tests in Publisher have been updated to use these test helpers.

`WorkflowActor` tests have moved to `Workflow` test, because they belong there.