Update SafeHtmlValidator to match content_models

Updated the validator to match the SafeHtml validator used in govuk_content_models this should be pushed to govuk_content_models in order to remove the duplication although it will create a breaking change. The main difference here is that the version in govuk_content_models validates all fields on an object no simply a specified field. This works much more like a railsesque validator and only validates a single field.
Rename SpecDocAttachProcessor more meaningfully

The SpecialistDocumentAttachmentProcessor does not need to be specific to Specialist Documents. It is actually a markdown processor specifically for attachments.

Similarly, in the wiring, markdown_processor is not accurate, this only deals with attachments so we will rename it to markdown_attachment_processor.
Rename SpecDocGovspeakToHTMLRenderer

As with the MarkdownAttachmentProcessor this is no longer specific to specialist docuements, but is actually reasonable to use with anything which responds to a bady method which returns something containing Govspeak.
Add body attribute to manual edition
Allow manual body to be previewed, edited and shown

Adds new routes for previewing the govspeak body and adds a form element for creating and updating the body attributes. Also displays the body govspeak on the show page
Export manual body as html to the content store

Before sending our govspeak body to the content store, prerender the govspeak as html
Rename updated_at to last_update
Remove a commented out method
Remove content api from manual publishing pipeline

Manuals are no longer published to content api but instead published to content store via the publishing api. This is a first step towards removing content api.

with @tommyp
Export to publishing api before rummager

We should publish content to content store before publishing to search. This is so that when something arrives in search there is no way a user can reach the page before the content is available in the content store
Remove Finder API integration

Now that Finder Frontend is pulling results from Rummager we don't need
to update Finder API when documents are publishing nor withdrawn.
Handle GdsApi HTTP error types

Instead of rescueing from specific HTTP errors raised by the panopticon registerer. Instead rescue from GdsApi::HTTPErrorResponse types
Reraise panopticon publication errors for worker

Re raise any errors created by the PanopticonRegisterer in order to catch them in the worker. This is something we would like to change. wrapper classes around the gds-api-adapters should handles errors and error logging themselves in the future. There is thought towards allowing the API wrappers to an object which stores the state of the publishing (PublishingTask maybe?) which could be handed to the worker in order to query the state of a particular publishing job. This would allow us to correctly raise an error in the worker without frivolously catching GdsApi exceptions and making the worker unaware off GdsApi.
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.
Fix typo in rummager stub and message reset

This did not fail or raise an error because:

 1. `rummager_api` is a method in the wiring
 2. The wiring is included in the entire cucumber World
 3. The tests using this were then matching original requests.
Add help for collapsibles

This help is only required for collapsible sections on manuals so add in a yield to format specific help and pass in the help from the manuals edit page
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.