Switch to Go Modules

[gerred]

This PR switches to Go Modules. Specifically, it:

1. Turns on Go Modules and removes support for dep.
2. Creates new shell scripts for handling code and manifest generation to workaround Go Modules with Kubernetes code generation tools. See: modules: pin dependencies and fix updategenerated projectcontour/contour#1010 for inspiration.
3. Introduces tools.go to represent binary tool dependencies with Go Modules and bind them to a semver. This is behind a build flag so that they are never compiled in. See: https://github.com/go-modules-by-example/index/blob/ac9bf72/010_tools/README.md for this method. (this addresses @runyontr's concern about tool versioning)
4. Updates README.md and CONTRIBUTING_GUIDELINES.md with this new information.
5. Make staticcheck happy by removing some unused test bootstrapping functions.
6. Adds module and binary caching to CircleCI. On a ~2-4 minute build, this reduces build times to ~1 assuming no dependencies have changed.
7. Streamlines the Makefile and removes explicit calls to generate and manifest during test, install, and run. This code should only change when APIs are changed, and are now covered in the Contributing Guidelines.
8. Kicks vendor/ to the curb by putting it in .gitignore.
9. Breaks your browser on reviewing files changed.

There's a few other static analysis tools I'd like to add around spelling, ineffectual assignments, etc., but we can separate that into another PR.

After this branch is merged, we should go through and delete all old, unused branches (except dynamic-crds as that is being re-written). There's no chance that code can reasonably merge being so far from master anyway. Additionally, this probably causes some merge conflicts with #166 - sorry @fabianbaier. Probably never a good time to rip this particular bandaid off.

There wasn't really a smaller way to make this PR happen. There's enough infrastructure changes that my additional little changes around the Makefile are incidental. They're also really helpful with speed given how we need to generate code now. Generating on every make task was slow already and IMO hinders a smooth development cycle.

BTW - if you have problems testing this, kill your existing package cache (rm -rf $GOPATH/pkg/) and try again. There seems to be a caching issue when having the same dependencies pulled by dep and modules. Not sure what the issue was there, but could not reproduce after removing that package cache. On a fresh clone with other projects in my $GOPATH this doesn't seem to be an issue.

[kensipe]

now that tests are working... test target should be part of the run requirement

[kensipe]

lgtm

nice work. I really like the immutable build tooling!

[kensipe]

there is an issue with having make test as part of the CI.
If rate limits are going to cause tests to fail... I don't want them to stop a PR build... however I would really rather have tests in CI :)

[gerred]

We should have tests in CI for sure. We need to really talk about removing our reliance on the Github API for day-to-day use anyway.

I'll hold it out for now, let's talk about this all live tomorrow to figure out a resolution.

[gerred]

@fabianbaier Go Modules does not use vendor/ and using GOPROXY is the encouraged form of module caching going forward.

[gerred]

oh, I'll fill you in via Slack. Basically, the diff was too large to reasonably review. We will do another PR removing vendor/ again and re-adding it to .gitignore

[fabianbaier]

lgtm