Swats away this annoying warning when the test is skipped due to GPG being
unavailable:

```
  1) Skipped:
GpgTest#test_create_test_key:
GPG Unavailable

Error:
GpgTest#test_create_test_key:
NoMethodError: undefined method `rmtree' for nil:NilClass
    /usr/local/Library/Homebrew/test/test_gpg.rb:11:in `teardown'
```

Closes #675.

Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>

Removes the detection logic from the Requirement in favour of it living inside
the Gpg class & us calling it from there. It's a bit nicer & avoids us calling
Requirement code from outside of direct requirement handling & fulfillment.

GPG 1.x has stopped receiving new features, some of which we may well want to
take advantage of sooner or later in Homebrew. Upstream has also been attempting
to work out for a while how well used it still is which suggests it may "go away"
at some point in the future.

Debian is also in the process of migrating GnuPG 1.x to a `gpg1` executable
whilst GnuPG 2.1.x assumes the `gpg` executable. There's a detailed video
discussion of this from DebConf 2015 at:
http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/GnuPG_in_Debian_report.webm

It's unsafe to assume every `gpg` executable is going to forever equal 1.x and
every `gpg2` executable is going to forever equal 2.x. MacGPG2 has been symlinking
2.x as a vanilla `gpg` for a while, for example, and we will be soon as well.

You'll still be able to plonk the `libexec/bin` path of `gpg` in your PATH to
access a vanilla `gpg` 1.x executable if you want to, but we're not going to
actively keep adding gpg1 support to formulae going forwards. There's really no
reason why 99.9% of projects should not or cannot use `gpg2` these days.

This uses detection methods to determine regardless of what the executable
is called we're always hitting a 2.0 GnuPG or nothing.

which_all already runs some checks to see if the file is a file & is executable.
Our usage here inside `self.available?` is mostly a smoke test.

Closes #676.

Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>

Add completions for --fetch-HEAD flag

update.sh: prevent overwriting UPSTREAM_BRANCH.

Closes #656.

Signed-off-by: Martin Afanasjew <martin@afanasjew.de>

UPSTREAM_BRANCH was being used both as a loop variable name and name
for the upstream branch for HOMEBREW_REPOSITORY. This meant that the
variable names were overwritten which prevented update.

Closes #693.

Revert "formula_versions: also silence stderr."

formula_versions: also silence stderr.

We already stop old formula versions printing stdout but this also stops
them printing on stderr for e.g. old deprecation warnings.

This would have caught the bug fixed in 985c67.

Otherwise this can prevent taps from being updated as expected.

Update --fetch-HEAD documentation

A failure to change a dylib ID or install name would previously cause a
rather cryptic error message, that didn't include the name of the file
that caused the failure, unless `--debug` was specified. Make sure to
output this information in all cases before re-raising the exception.

This can just live in `brew.sh` and then it doesn’t need repeated in
all the other places.

Tweak the logic further to make the no-op case even faster.

Before:
```
brew update  1.10s user 1.05s system 92% cpu 2.325 total
brew update --preinstall  0.60s user 0.77s system 96% cpu 1.433 total
```

After:
```
brew update  0.60s user 0.34s system 83% cpu 1.132 total
brew update --preinstall  0.29s user 0.24s system 62% cpu 0.860 total
```

These times are now fast enough to avoid any further special-casing for
`--preinstall`, roll it out to users by default and not print a message
unless we've actually found some updates.

Fixes the case where I have `mysql56` installed but do
`brew uninstall foo/bar/mysql56` which isn't a valid formula.

Fixes https://github.com/Homebrew/legacy-homebrew/issues/39883.

Fixes #672.
Fixes #673.

This hasn't been an issue for upstream stable releases for 3 years, since March
2013, and hasn't been an issue for pre-release versions for 4 years.

That release, and indeed the latest modern GPGTools releases, support 10.6 and
above so there's no reason to suspect people are actually encountering the old
versions in the wild with enough regularity to merit this being a permanent part
of our codebase any more.

In the last two years Homebrew has seen one Issue where MacGPG2 was the problem,
and that wasn't reproducible at the time (and still isn't), and the `doctor` check
likely wasn't even raised there. There has only been one Issue where the MacGPG2
`doctor` check was raised in that two year period.

I think it's fair to treat this as an user configuration outlier now rather than
an issue we need to be constantly on guard for.

Ref: Homebrew/legacy-homebrew@dfb171b
Ref: Homebrew/legacy-homebrew#12238
Ref: Homebrew/legacy-homebrew@046498b

Avoid some duplication (thereby also shortening line length) and put
everything in a single string for output via `echo`.

Fixes #671.