Move Travis CI make task into a bash script

Move the make task for Travis CI to a bash script. This is in
preparation for removing the Makefile.

Also, simplify the command-line options for `go test`; `-test.v` has the
same behaviour as the shorter `-v` and `-run` is removed as all tests
are run by default so this was unnecessary.
Remove Makefile

Remove the Makefile because:

  - it removes a dependency on `make(1)`
  - a lot of the tasks, e.g. `vagrant-up`, add little value
  - the `RUN` variable unnecessarily adds the `.+` regex; the default is
    to run all tests anyway
  - as we add more flags (i.e. vendor-specific flags), using a Makefile
    obscures these options
Skip 'install' step

Tell Travis CI to run `true(1)` for the `install` step.

This is to prevent Travis from running `go get -v ./...`, which fails[1]
with:

    ./helpers.go:117: undefined: edgeHost
    ./helpers.go:146: undefined: client
    ./helpers.go:147: undefined: requestSlowThreshold
    ./helpers.go:150: undefined: debugResp
    ./helpers.go:215: undefined: client
    ./helpers.go:276: undefined: edgeHost
    ./helpers.go:279: undefined: originServer
    ./helpers.go:346: undefined: originServer

I believe this is due to the way we're using flags in a suite of tests
(running `go test` works fine).

We don't need to run `go get` as we don't have any package dependencies
outside of Go's standard library. By skipping Travis' `install` step, we
prevent it from running `go get`.

Note that it that this wasn't a problem before because Travis apparently
doesn't run `go get` if it detects a Makefile[2], which is consistent
with the documentation here:
http://docs.travis-ci.com/user/languages/go/#Default-Test-Script

[1]: https://travis-ci.org/alphagov/cdn-acceptance-tests/builds/33156531
[2]: https://travis-ci.org/alphagov/cdn-acceptance-tests/builds/33047132
Rename common_setup_test.go to main_test.go

Which better follows Go convention.
Merge pull request #93 from alphagov/75804242-consolidate-docs

[#75804242] Consolidate documentation on how to run the tests
Alphabetise command-line flags
Add flag to specify vendor-specific tests to run

Different vendors supply different headers, so we need to vary the tests
accordingly.

Add a new command-line flag, `-vendor`, which takes a string denoting
the name of the vendor against which we're running the tests.
Add message as constant for vendor-specific tests

When a vendor-specific test does not apply to the vendor specified, we
need to skip that test. Add a message as a constant so that we can
re-use it as necessary.
Repurpose X-Served-By test to be generic

Repurpose the `X-Served-By` test such that it supports multiple vendors,
not just Fastly.

Also, add support for Cloudflare's `CF-RAY` header.
Rename `testForFastly` to `vendorFastly` etc

To make it clearer that we are referring to vendors.
Adjust check based on new vendor flags

Amend `TestFailoverErrorPageAllServersDown()` to use to the new vendor
flags.

Defaults to Varnish's "Guru Meditation" error message as that's what is
used by the mock tests.
Remove stringContainsOneOf function

This is no longer being used as of the previous commit.
Add -edgeHost flag to examples

It's the most common use case (i.e. running against a real CDN rather
than the mocks), so we should include it in the examples.
Explain how to run the tests against Vagrant
Feature-flag ClientIP test for Cloudflare

Use the new vendor flag so that `TestReqHeaderXFFCreateAndAppend()` is
not run if we're testing against Cloudflare, as we know they do not
yet support this feature.

Also, tidy the sort order of the variable definitions and use `:=` for
assigning `sentHeaderIP`.
Fail test when no vendor implementation known

Fail, rather than skip, a test if we haven't written test logic specific
to that vendor.

The aim of this is that new vendors will causes the tests to fail,
meaning that either:

a) the test should be modified to skip that test if the feature is
_known_ not be supported by the vendor, or,

b) the test should be modified to support the vendor's unique
implementation of the feature if it's supported, or,

c) the vendor CDN configuration needs modification to make the tests
pass

This will allow us to distinguish between features we know to be
unsupported, features that are supported but we don't yet test correctly
for, and features which have not yet been correctly configured in our
CDN account.

Note that we specify Fastly as the vendor when running the mock tests
(also used by Travis) as Fastly are our current vendor and the mock
virtual machine roughly emulates Fastly's service. If we didn't specify
Fastly when running the Travis CI tests, the tests would fail with
'notImplementedForVendor' errors.

* * *

Also, fix a syntax error where `t.Skip()` was called as `t.skip()`.
Alphabetise constants
Add 'Guru Mediation' error page to mock config

Add a 'Guru Mediation' (sic) error page to the Varnish mock
configuration to match Fastly's error page which contains this same
typo.

Since the Varnish mock configuration already mimics Fastly's behaviour,
it makes sense to extend this to the error page. We can then look at
mimicking other CDN vendors using the mocks as necessary in future.

This page is adapted from Varnish's built-in `default.vcl`[1] with a
noticeable difference that I had to add `+` as a concatenation error,
otherwise the VCL fails to compile with the error:

    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: Expected ';' got 'obj.status'
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: (program line 174), at
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: ('input' Line 157 Pos 15)
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns:     <title>"} obj.status " " obj.response {"</title>
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: --------------##########----------------------------
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns:
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: Running VCC-compiler failed, exit 1
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns:
    Notice: /Stage[main]/Varnish/Exec[varnish-restart]/returns: VCL compilation failed

This is also necessary to make the CI tests pass since we're modelling
our Varnish behaviour on Fastly.

[1]:
https://www.varnish-cache.org/trac/browser/bin/varnishd/default.vcl?rev=3.0
Use a simple string for empty synthetic response

`{"` is used for mainly for multi-line strings, whereas a simple string
would suffice here:
https://www.varnish-cache.org/docs/3.0/reference/vcl.html