Enable quarantining of Homebrew-Cask's downloads

superenv: Use 02 optimization flag for Linux builds

docs/Maintainer-Guidelines: add lead maintainer guidelines.

go: support & use aggressive caching

text_cop: update `cargo build` cop

Add `$LOAD_PATH` for RuboCop cops.

Fix executable with spaces.

I hadn't planned to move on this so quickly but impressively core
today had its first Go Module using PR, so this has become more useful
than it would've been. Useful reading on the Modules system can be found
via https://golang.org/doc/go1.11#modules.

`GOCACHE` has been a thing for a while but it hasn't really been
especially beneficial to us, so I've ignored it, but with the Go Modules
system it can be incredibly useful in reducing build times & thus CI
burden. A lot of this is explained rather nicely here:
  https://groups.google.com/forum/#!msg/golang-dev/RjSj4bGSmsw/KMHhU8fmAwAJ

The upsides here for us are obvious:
1) We do a *lot* of go-based builds, and the more things move over to the
module system the more comprehensive that cache will become and we'll
need to remotely fetch less dependencies, which massively speeds up
build times even on high-speed connections.
2) Module dependencies aren't limited per formula. If `hugo` fetches a
dependency that is the same version as, for example, `wiki` also needs
`wiki` won't bother to fetch that version remotely but instead will
simply pluck it out of the cache.

If we look at `hugo`, because it's the only formula so far with Module
support:

First build: `built in 1 minute 41 seconds`
Second build: `built in 14 seconds`.

It's worth noting perhaps that we can use just the module cache rather
than the build cache + module cache combination, but doing so leads to
a significant reduction in regained build time. A build under that
system pops an average build time with `hugo` (after the first build)
of ~70 seconds, which is only a 30 second saving on the first build.
However, if we wanted to speed up builds whilst also not eating big chunks
of disk space that is an option.

The downside of a build cache + module cache system is disk usage.
`go` does not exactly eat up disk space sparingly, and the cache size
from `hugo` alone is 258.8MB. That could be an issue on CIs where disk
space is already a squeeze at times, but it's not much different to how
we let the `java_cache` behave now.

All Module-supporting formulae need to do to use the shared cache is
instead of deleting the `GOPATH` env we set everywhere replace it with
this:
```
ENV["GOPATH"] = "#{HOMEBREW_CACHE}/go_cache"
```

`-Os` produces sometimes bigger binaries on Linux.
Also, llvm built with `-Os` is really slow at runtime for Linux.

Using `-02` aligns us with what Debian does, and as we are compiling most of our stuff with gcc (and not clang), it makes sense to use `-02` on Linux.
`-Os` does probably slightly different things when used on mac with llvm, compared to when it is used with gcc on Linux.

style: Fix npe and add test for corrected offense results

audit: Use `fetch` with default value prevent NPE

Don’t use `CLI::Cleanup` in `Auditor`.

audit: Add null check on style results

Check version conflicts using linkage.

Instead of refusing to install software preemptively by assuming
multiple linkage to differing versions of the same library we now make
`brew linkage --test` verify that we don't have two versions of the
same library linked at the same time.

This will be considerably more permissive whilst checking the actual
problem that we're worried about.

extract: update docs

Preliminary blurb in documentation about using brew extract to obtain deprecated/deleted/particular versions of formulae.

audit: Show RuboCop offense correction status and count in output

Add new extract dev command to retrieve old versions of formulae

Instead of just blanketing over with monkey-patches like before,
set up monkey-patches as needed, and make sure to clean up after
we're done.