58501480 publishing service objects

Tracker: https://www.pivotaltracker.com/story/show/58501480

This implements the first two edition service objects (`EditionPublisher` and `EditionForcePublisher`) for managing edition workflow actions in a cleaner, more decoupled manner. The idea is that the lifecycle events that are triggered when actions are performed on editions should be both decoupled from the `Edition` model itself, and configured and managed using a standard interface. This makes the code: easier to reason about; easier to change; easier to test. Examples of these lifecycle events include: GOVUK Delivery notifications; author notification emails; search (re-)indexing. At present, these are implemented using a mixture of callbacks, observers and controller action code.

The service objects are implemented as simple method objects that perform the action in question, without performing any of the related lifecycle events. Instead, we now have a simple message bus to which interested parties can subscribe for a given action. A successful action will result in all subscribers being notified, and they can then perform any lifecycle events separate from the action itself.

The clearest example of how this improves the code is with the GovUkDelivery notifications. Previously, this was implemented by mixing in a module to those edition classes that should send gov delivery notifications. The mixin added an `after_publish` callback, which then delegated out to the gov delivery code to send the notification. With this new code, Edition classes no longer need to know about gov delivery, and are simpler as a result. Instead, we simply hook the gov delivery code to listen for the publish events, and let it handle the notifications.

The remaining actions to be converted to service objects are: submit; reject; unpublish; schedule; unschedule; approve retrospectively; convert to draft.