Once URLs are registered, forward the request to the content-store

This wires in a fake content-store server which always responds with a
200 OK status code and a sample content-store body. Then we test that
sending a PUT request to the publishing-api muxer calls through to the
url-arbiter and then the content-store in the correct order. This
tests the intended behaviour.

Because we don't want to duplicate logic already implemented in the
content-store application we're proxying the original request we were
provided through to the content-store using a
`httputil.NewSingleHostReverseProxy(*url.URL)`. This can be handed the
parameters from a `http.HandlerFunc(w, r)` in the form of
`ServeHTTP(w, r)`.

However, it's not possible to read from the `http.Request` body twice
in Go. This is because `r.Body` implements the `io.ReadCloser`
interface. An `io.ReadCloser` is an interface that implements two
interfaces, one of which is the `io.Reader` interface.

Upon being read an `io.Reader` will do the following upon all
subsequent reads (taken from docs):

> The next Read should return 0, EOF regardless.

This means that we can't forward our `http.Request` onto our
`httputil.NewSingleHostReverseProxy`. Doing so would cause us to send
an HTTP request with a ContentLength of the original body but no body
able to be read.

To get around this we copy the raw bytes from the request
body (`r.Body`) using `ioutil.ReadAll` into a buffer we own. Then we
overlay two separate `bytes.NewBuffer` instances, which will allow us
to drain the instances as `http.Request` and `io.Reader` expect.

Finally, we implement the `io.ReadCloser` interface on top of our
`bytes.NewBuffer` copy and replace the original `r.Body` with itself
so that it can be read by the `httputil.NewSingleHostReverseProxy` and
then closed successfully as the underlying Go code expects.