We only want the site's builder dependencies as part of the builder
image, instead of it being a builder + built site.

If we have to build the site into the image, this requires us to `COPY`
the whole directory structure of the site. This means we can never use a
cache for the image, due to the site always being different. Therefore,
if we instead push just the downloading of Ruby and NPM dependencies,
then we'll be able to cut down time in CI by only rebuilding on
dependency changes.

Note that I've change the folder structure such that we can place our
Ruby and NPM dependencies into the `/app` folder, so we can ensure that
when we volume mount the the actual site's contents into `/app/site`,
the `node_modules` folder will remain, and we can reference all our
tooling through `PATH` manipulation.

We need to perform the `gulp build --production` inside our GitLab CI,
rather than in the image - note that this explicitly needs to be done
due to the default action of the container being `gulp serve`.

We required the running of the old image as a daemon process such that
we'd be able to grab the already built site from the running image.
Therefore, we can now simply just run the builder with a volume mount
which will ensure that the `_site` folder exists in the source
directory.

Using the environment variable `BUNDLE_WITHOUT` instead of having it
inside the `.bundle/config` file due to the mounted site in `/app/site`
will not have `.bundle/config`, as it is installed into `/app`. However,
we can avoid this by utilising an environment variable. Additionally,
due to Docker's `ENV` functionality, this will then be passed into any
commands run under the container i.e. the `gulp build`.

We have our NPM dependencies downloaded first due to the fact that they
_should_ be changed less than ie Jekyll or Capistrano, so we may as well
cache them with preference over Bundler.

Due to the builder image no longer having the built site inside it, we
now need to pull the built image and place it in the directory we're
expecting it to exist in, then volume mount that for our tests.  The way
we do this is as with our deployment, as per `config/deploy.rb`.

Closes #174, #192.