Require Go 1.8 for dep

[sdboyer]

Right now, we retain support for Go 1.7. The main pain point this causes is that we have a bunch of junk sorting types, just itching to be replaced by sort.Slice().

I'd like to replace these once we think it's safe to do so. One reasonable measure for "safe" could be the state of the RHEL repositories (or at least EPEL). CentOS seems to have 1.6, and RHEL none at all; EPEL has 1.7, assuming I'm doing that search right.

[timothysc]

I'd absolutely never depend on a distros version of golang unless you want to be sorely disappointed. I create a clean GOPATH and vendor my deps and use https://github.com/travis-ci/gimme to manage my golang versions.

As an ex-hatter this is how we managed our own non-containerized builds. For containerized builds, this just goes away...

I'd say just pull the trigger.

[sdboyer]

now that 1.9 is out, doing this is fine