Add a new Consultation Response model

This is the first step toward changing how Consultation Responses are
modelled.  I plan to rename the model to ConsultationResponse but that
name's currently in use as a subtype of Edition.
Associate attachments with Consultation responses

We should now be in a position to build responses and their associated
attachments directly from the Consultation.  The next step will be to
migrate existing Consultation Responses to this format and add the
relevant fields to admin Consultation form.

It feels slightly odd to use a full model
(ConsultationResponseAttachment) when a habtm relationship would do the
trick, but I think habtm relationships are somewhat out of favour.
Copy the response to new consultation drafts

When creating a new draft of a published consultation, we need to create
a new response based on the attributes of the existing response, and
link the original attachments to that new response.
Fix typo in test name
Prevent creation of empty consultation responses

This should prevent a response being created when no data is entered for
the response or a response attachment, on the consultation form.  *NOTE*
The addition of the form fields to the form is on its way, this is just
in preparation.
Add validation to Consultation Response Attachments

It shouldn't be possible to create these join objects without the two
objects they're supposed to be joining (Response and Attachment).
Revert "Add validation to Consultation Response Attachments"

This reverts commit de48aa01fffbbae22bd4ffbd48a8468a79ad961e.

The presence of this validation makes it difficult to build a nested set
of objects (from the consultation to attachment through response and
consultation_response_attachment) so I'm going to revert it for now.  It
can always be added once we can actually create these objects through
the web interface.
Don't build empty consultation response attachments

This should prevent us ending up with empty consultation response
attachments.

I've copied `all_blank_or_empty_hashes` and the related
`hash_with_blank_values?` from Consultation.  We should probably DRY
these up at some point.
Allow nested attribute deletion of response attachments

This'll allow us to remove the join between a Consultation response and
attachment, while leaving the attachment in place.  We need to leave the
attachment as it'll still be associated to older editions of the
consultation.
Add responses to admin consultation form

As of this commit, we have two ways of creating 'responses'.  The
original method of creating Consultation Responses that are themselves
Editions, and the new method of creating Responses.  I'll soon be
migrating the existing Consultation Responses to Responses and removing
the ability to create the traditional Consultation Responses.

I've added the basic fields for creating attachments with the response
but plan to replace this with the attachment_fields partial (or parts of
it) in a later commit.

I don't like the `if @edition.is_a?(Consultation)` condition in the
editions/show template but I'm going to live with it for now.
Re-use attachment_fields partial for response attachments

Re-using this partial gives us all of the additional, optional,
attachment fields for free.  I've amended the response controller test
to assert the presence of these fields because at the moment they're
only visible because `Consultation#allows_attachment_references?`
returns true.

I've had to change the attachment_fields partial to allow us to define
whether or not we should be displaying the inline attachment markdown
help snippet.  This is so that we can continue to display the help for
the attachments on the consultation but not for those attachments on the
response.
Allow empty response attachments

This should've been part of the previous commit
(fb7cfc8d48e527ec3d5dff71203c6c1b5793a46c).  Before this fix, creating a
new consultation would complain that the attachment title and file were
missing, irrespective of whether you were trying to add a response
attachment or not.  This is because the 'accessible attribute is always
sent.  I've copied the logic from the Attachable mixin to deal with this
attribute.

There's a failing feature in the last commit:
editing-draft-consultations.
Remove the actions to create/view consultation responses

We're moving to a world where consultation responses are created as part
of the consultation itself.  Before this commit you could still create a
Response (the new type) and a Consultation Response (the old type).
While you can still create a Consultation Response if you know the URL
this'll prevent people navigating to that form through the interface.

The next step is to migrate all the Consultation Responses to Responses
and remove all the old logic completely.

*NOTE* I've removed two features in this commit because they were
describing what happened when you create Consultation Responses.
There's probably an argument to say that I should've replaced them with
something that describes the creation of a Response in the new world,
but I don't have the energy.
Merge branch 'master' into remodel-consultation-responses
Remove Consultation#latest_consultation_response

This was made redundant in the commit that removed the link to view the
latest consultation in the admin publisher.
Replace use of ConsultationResponse with Response

I haven't removed the Consultations Responses yet as I still need to
copy the data from those responses to the new Response objects. As soon
as the data has been removed I'll be able to remove all the other code
that's hanging around to support Consultation Responses.

I've kept as similar an API as possible for Consultation in an attempt
to limit the amount I had to change in this commit, which is why we
still have `#published_consultation_response`, `#response_published?`
and `#response_published_on`.

There's not currently any validation to ensure that you choose an
alternative format provider if you add a response with an attachment.

I've had to amend the json representation of a consultation.  The only
failing test was a functional test so I'm hoping that I haven't
inadvertantly broken something that relied on the previous json
representation.
Copy Consultation Responses data to Responses

Here's a rough overview of the logic of the migration:

* Find the unique set of Documents for all the Consultation Responses in
  the database.
* Find the published, or if none are published then the most recent,
  Consultation Response for each of the Documents.
* Find the published and, if it's different, the most recent
  Consultation for each of the Documents.
* Copy the attributes (summary, created_at and updated_at) from the
  Consultation Response to a new Response for the Consultation.
* Copy each attachment from the Consultation Response to the new
  Response.

I've redefined the active record objects in this migration with only
those associations and methods that I need for the migration itself.
Remove Consultation Responses from database

Consultation responses can only be associated with attachments (through
edition_attachments) so that's the only join table we need to remove
records from.  *NOTE* We need to keep the attachments themselves because
they'll be linked to Responses through the
consultation_response_attachments join table.
Merge branch 'master' into remodel-consultation-responses
Remove Consultation Response admin route and controllers

Users can no longer navigate to this route (Responses are no longer
modelled as Editions) so we can safely remove the route, controller and
associated test.