Remove ManualDocumentObserversRegistry

There are no observers for manual documents, so just get rid of it.
Stop exporting manual sections to Panopticon

Only the manual itself needs to be exported to Panopticon for the
purposes of tagging with Organisation and Specialist Topics which allows
it to be included in specialist browse pages.

We have to continue exporting manual change notes for now in order to
register their route. When we changed manuals to be exported to the
Content Store instead of Content API we moved change notes to be part of
the details hash of the manual itself, rather than being a stand alone
document. That means Content Store isn't registering the route for the
change notes. Leaving the Panopticon registration in is a workaround and
should be addressed in the future.
Merge pull request #257 from alphagov/remove-manual-sections-panopticon-integration

Remove manual sections panopticon integration
Abstract common Document observers registry code

Observers should be the same for all SpecialistDocument types, so let's DRY up the code here.
Add exporter and formatter for email alerts

Following the patern of

* Things that send data to an API = Exporter
* Things that an exporter uses to format for an API = Formatter

The EmailAlertExporter exports formatted emails to the GovUkDelivery API
Add EmailAlertExporter to publication observers

Wire up the EmailAlertExporter in the publication observers chain for SpecialistDocuments. This should be the last thing in the chain so that we only notify users of a new SpecialistDocument publication once it is fully available on the frontend.
Features to test publication alert workflow
Move Publication alert formatting into a view

|Instead of rendering text directly in the Formatter, use ActionView to render an erb view.
Add more meaningful copy to the publishing email

In order to allow human readable copy to email alert we need to provide some custom humanized attributes to the formatters. Instead of binding the formatters to the schema instead we will subclass the formatters to provide this information
Ensure that a topic exists before publishing to it

In order to create a new publication email we should ensure that a topic exists in the publication api before trying to export a notification for that topic.
When republishing, dont send email notifications

When republishing from a script we do not want to notify users. Instead use a separate set of observers in order to republish documents in the system.

This is a system only journey and is non user facing!
Merge pull request #260 from alphagov/feature/send-email-on-publish

Send email alerts on publish
Improve display of long metadata value lists

For metadata that can have multiple values (eg therapeutic_area for a
drug_safety_update document) place each value into a separate `dd`.
Merge pull request #262 from alphagov/improve-display-of-metadata

Improve display of long metadata value lists