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.