Running XSS validations is computationally expensive.

The CI build time almost doubled after adding the XSS validation
checks. After some investigation it was apparently that as soon as
we perform *any* Govspeak validation, the test time increased
significantly (validating even a single attribute increased unit
test times by 20%; validating two attributes increased time by 50%).

In order to speed up validation times in tests, I've introduced a
cache so that any particular input string is only validated once.
Since in tests many of the edition bodys and titles will be
identical, this avoids most of the computational cost of validating
our test models.

Here's a comparison of times (in seconds) with and without caching
on my local machine:

 Test        | With cache | Without cache
----------------------------------------
 Unit        | 56.49      | 105.56
 Functional  | 177.02     | 371.75
 Integration | 0.66       | 0.64
 Cucumber    | 137        | 163
Add description to document series database table
Allow admins to add govspeak description to document series.

* Add tests for functionality added in previous commit [1].
* Display the series description on admin & public-facing show pages.
* Added tests to check it's possible to use govspeak.

[1] 6b648ab764a732b9654319432768c98d97c34add
Move the styles for document series markup into publications styles.

* Since these styles are only used on the publications show page, it makes
more sense for them to live within the publication styles.
* Also I was initially confused that these styles might apply to the
document series show page.
Add some space around the description on document series show page.

As requested by Neil.
This returns an Edition, not a Document.

Gotta be careful of nomenclature.
Deny WAP requests to public controllers with 406

Google is crawling us with a WAP-like browser, which causes fatal errors
due to missing response formats.

Additionally, as our site will not function well on WAP connections due
to the large size of assets etc. we serve, we should deny the
connection until a better site is in place.

Note that using a blanket:

    respond_to :html

in the controller doesn't work for some reason, hence the filter.
Ensure that we're logged in.

I'm a bit surprised that this worked in CI; that it did implies that
some data is being left around in the database (specifically, a
user record).
Expose the format of the specialist guide

This is to match the set of known attributes which the mainstream content API provide.
Include an ID parameter in the specialist guide API.
The mainstream API exposes this as 'related'.
Include ID in the related API JSON.
Include the _response_info status hash, as in mainstream.

I would've like to contain the `_response_info` generation within
the presenter, but it doesn't seem like there's a trivial way to
indicate the response code for the controller within a custom
presenter like this.

Note also that the index *always* returns "ok"; I don't think there
is a scenario where the index would return something like "not
found" at the moment.
The API should respond with HTML without a govspeak wrapper div.

I think the govspeak helpers are ripe for refactoring into a
class which can be structured and tested a bit more clearly; at the
moment it's a soup of methods calling other methods. I had wanted
to simply pass an option (`wrap_in_govspeak_div: false` maybe) to
the method calls, but I lost confidence in how fast this would be
given the multivarious different entry points to govspeak rendering.
Omit per-record _response_info in collections.
Fix the broken build I caused.

I'm not sure why stubbing the `govspeak_to_html` methods caused this
problem, but stubbing the underlying `bare_` methods fixes the
build.

Like I said in c9b34539a9af63e51c5748df0b1d4c5d9305c3f0, I think
these helpers need to be collected into an actual Object.
Merge branch 'master' into remodel-consultation-responses