Use an alphagov fork of the redis library

In the last 24 hours a bug was added to the Redis library that we're
using. The bug has been tracked[1] and a small test case[2] has been
written to reproduce it.

In the mean time, we're going to use a fork of the radix Redis library
that we pin the version for instead of directly checking the library
into a `third_party` directory using `third_party.go`.

This was discussed with @bradleywright as the right thing to do short
term until we can get around to fixing the library in question.

[1] https://github.com/fzzy/radix/issues/35
[2]
https://github.com/KushalP/radix/compare/try-to-reproduce-bug-as-tests-added-in-35

P.S. We still haven't defined a consistent way of managing
dependencies across alphagov projects that have been written in Go.
This was deemed a good enough solution to unblock us for now.
Merge pull request #65 from alphagov/use-an-alphagov-fork-of-the-redis-library

Use an alphagov fork of the redis library
Rename `HTMLBody` field to `ResponseBody`

We're going to support more MIME types than just `text/html` now, so
we should generalise the field.
Wrap the HTTP Response in a `CrawlerResponse` object

This can then hold both the Body and any HTTP headers we want to pass
around and reuse.
`CrawlerResponse` object owns whether or not the body `isHTML`

This is now owned by the respective object as it has ownership over
the HTTP Body response.
Rename `IsHTML` method to `IsBodyHTML`

The `CrawlerResponse` now holds both the header and footer for a given
HTTP response so we can check the actual Content-Type rather than
just matching between `plain`, `html` and `octet` text strings.
`ContentType` returns the content type as a string

This removes any of the extra information that usually litters the
Content-Type for our various different application stacks as well.
Add a list of constants for the content types we're supporting

For now, these will be the content types that we'll accept and write
to disk.
A response can tell whether it holds an `AcceptedContentType`

To make it easier to tell whether or not a given response is supported
add a helpful method on the object that can tell us quickly if that's
the case.
Improve logging for `WriteItemToDisk` workflow function

Rather than using the same log message for, make them specific.
Set Content-Type HTTP header and remove `expectedFilePath` variable

Update these tests for the `item.RelativeFilePath()` so that they
still behave as we expect before we start to manipulate the underlying
code to support multiple file formats.

Also removed the `expectedFilePath` variable as it was confusing to
follow. It didn't make sense to keep on changing this single variable
when the reference could just as easily be kept inlined. This is now
the case so the tests are more self contained.
`WriteItemToDisk` writes non-HTML responses to disk and acknowledges

Non-HTML responses can't be forward on for extraction, so we want to
write them to disk and acknowledge them immediately.
Remove `IsBodyHTML()` method from `CrawlerResponse`

This has been superseded by the `ContentType()` and
`AcceptedContentType()` as we're going to be supporting more content
types than just HTML.