Add republish tasks

This adds a PublishedSlugRegisterer class, which performs whatever
registration is necessary to inform upstream apps about content, when given a sequence of slugs for published
content.  It logs the actions taken, including producing a listing of
all slugs supplied to it by whether they were successfully processed,
not found, or gave an error when being processed.

Uses logic copied from the old panopticon registration rake task to
retry panopticon registration up to 3 times for an artefact if it times
out.  We only try the registration once with the content store, since we
expect that to be a much more reliable api endpoint.

We send updates to the content store with an update_type of "republish".

The new rake tasks are all very simple; obtaining a list of slugs, and
passing them to the registerer.  Several tasks are supported:

 * `rake reregister:all`
    Re-register all published editions

 * `rake reregister:by_mainstream_browse`
    Re-register published editions tagged to a browse page, read from
    the BROWSE_PAGE environment variable

 * `rake reregister:by_organisation`
    Re-register published editions tagged to an organisation, read form
    the ORGANISATION environment variable

 * `rake reregister:by_topic`
    Re-register published editions tagged to a topic, read from the
    TOPIC environment variable

 * `rake reregister:slugs_from_stdin`
    Re-register published editions for slugs read from stdin

I've run these tasks successfully in my dev environment, checking
manually that they update content-store and panopticon (and as a result,
search).

This PR also removes the old `panopticon:register` task, since this is superceded by `reregister:all`, and updates the PublishedEditionPresenter to allow setting the `update_type` appropriately for republications.

I still need to finish writing some tests for the PublishedSlugRegisterer, but would appreciate review of the structure of this in the meantime.
I'm not sure it's a good idea to define this directly within a `context` block, it would be more typical to use a `setup` block for these.

In fact I'm not sure at what point these will be evaluated.  I suspect it'll be at parse time, and therefore outside any transactions.  This means that they won't be torn down after the tests, and can therefore leak into other tests.