Add content_id field to documents.

Migration to create the field. The content_ids will be populated
separately in a data migration.
Data migration to ensure documents have a content_id

it's better to do this in a data migration so that we are sure that the
application server code has reloaded when this is run.

If this was done in a database migration then there would be a race
condition where:

* all documents had had a content_id set
* application code had not reloaded
* user creates a new draft document which does not get the content_id
  set

We then end up with a few documents without content_ids.
Ensure that content_id is set on new documents

The Edition::Identifiable module handles the integration between
edition and document including the initialization of Documents.
Exported json for an edition should include content_id
Data migration to republish all published editions to the content store

This will enqueue sidekiq jobs to actually perform the republishing for
each edition
Allow update_type to be overridden in publishing api presenters

Sometimes we'll need to send documents with an `update_type` of
`republish`. Therefore we need to be able to pass this option into the
presenter.
Options passed to the API worker should pass to the presenter

We want to be able to 'republish' documents, so we need to be able to
pass an `update_type` option to the worker.

In an ideal world the test case for this could have been neater. But the
helpers provided by gds-api-adapters do not allow stubbing requests
without doing an exact match on the body json, so we need to
render the entire presenter output.
DataHygiene::PublishingApiPublisher should 'republish'

Updates should be sent as 'republish' messages. The only use case for
this class is bulk-republishing already-published things, so it seems
reasonable to make this the default.