Allow html_args to be passed to nested_attribute_destroy_checkbox_options

To avoid the hideous:

    checkbox_args[0].merge!(label_text: 'blah')

that we see everywhere that it is being used in a view.
Feature to describe new attachment behaviour
Provide new "keep/remove/replace" UI for attachments

Still need to deal with this in the controller, but it seems ok as a first cut at the UI.
Extract complex view logic for attachment data to helper methods

Seems nicer in here, and we make the radios inline to save on space.
New helpers for fields about attachment do nothing if the object is new
Don't render the id, instead put it in a new field (to_replace_id)

This should mean we always create a new AttachmentData object with the replacement file, and we can use the to_replace_id to manipulate the existing object to tell it that it's been replaced.
EditionControllers that allow attachments cope with attachment_action

They will massage the provided params to make sure that:

* 'keep' attachments aren't inadvertently removed or changed by removing the attachment_data_attributes and _destroy params
* 'remove' attachments are destroyed by adding the _destroy param
* 'replace' attachments are definitely creating a new attachment_data by removing any id param inside attachment_data_attributes

We don't do anything if the edition_attachments_attributes params don't include an id param as that's creating a brand new attachment and these keys shouldn't be present.

Note: we have place-holders for AttachmentData#to_replace_id= and AttachmentData#replaced_by so for now, the tests still fail.
AttachmentData instances can now be replaced

AttachmentData#replace_with! will set the (new) replaced_by association on the instance.  It also walks the object graph backwards so that replacing an instance (x) that is already a replacement will set the instances that x replaced to be replaced_by the instance we are replacing x with.

We can trigger all this from the original instance by setting the virtual attribute to_replace_id.  During save this loads the AttachmentData instance referenced and calls replace_with! on it.
Redirect to the replacement for any AttachmentData with a replaced_by
Remove helpers for attachment action/replacement from the FormBuilder

The attachment_fields partial is used by things that aren't Editions so the form builder in use isn't necessarily an EditionsFormBuilder and wouldn't have those methods available.  Just turn the methods into normal helper methods that take a form builder instead.
Extract attachment_action handling from EditionsController::Attachments

Things that aren't editions can have attachments and their controllers will use the attachments_fields partial but not the EditionsController::Attachments module.  Therefore the code for handling the attachment_action param needs to be available outside of that module.
Handle attachment_action / replacements for consultation responses
Features tagged '@quarantine-files' uploads behave more like production

We stub Whitehall.clean_upload_path to return a new, test-specific, location and arrange Carrierwave.incoming_root and Carrierwave.clean_root and the virus-checking step to be more production like.  E.g. files that have been virus checked are not placed into public/.  This means that rails default ActionDispatch::Static middleware doesn't jump on incoming urls for attachments and avoid the AttachmentsController and so we can test the real behaviour.
Change attachment data replacement logic

An attachment that is visible is always shown.  We only look for replacements if the attachment is not visible, with a final fall back to the placeholder if it hasn't been replaced.
Make AtachmentData#replace_with! more robust

We use update_column instead of save! because we don't care if the AttachmentData is valid or not, we're replacing it regardless.  Also, current setup of carrierwave means every AttachmentData instance is invalid once saved because files are not stored in a carrierwave retrievable place.