e.g. Caskroom/homebrew-cask.

Thanks to UniqMartin for the fix.

Fixes #655.

Doesn't feel like a good reason to abort installation for users if the
formula author has specified a conflict that doesn't exist. Instead,
behave more like the `TapFormulaUnavailableError` but print a message
telling people to report to the formula authors.

Closes https://github.com/Homebrew/homebrew-versions/issues/1327

This reverts commit 24f7e671.

Closes #648.

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

Closes #584.

Signed-off-by: Xu Cheng <xucheng@me.com>

Introduce `--fetch-HEAD` option. Without this option upgrade and
outdated never fetch latest upstream commit to detect if HEAD is
outdated -- tabs are used instead. However, if option is passed,
we fetch commit from upstream, which is more time consuming,
but we can be sure that version is up-to-date or outdated.

* add `latest_head_version` to return latest HEAD version installed
* add `latest_head_prefix` to return Pathname with latest HEAD version
* add `head_version_outdated?` to check if HEAD version is up-to-date

If we try to call `Formulary.from_keg(f, :head)` on the keg that
is not HEAD-keg itself, we don't need to update commit of
returned formula and should use just HEAD version with nil commit.

Same is true for `ARGV.resolved_formulae`

This basically started once our integration tests caused the overall
test time to raise above 10 minutes, causing some coverage data to be
dropped because SimpleCov believed it to be stale.

When running on Travis CI, both the Linux and macOS build will send a
coverage report, causing them to be merged by Coveralls. This results
in inferior coverage due to the early stage of the Linux-specific tests
and is probably not what we want. Make sure we only send a report for
macOS (assuming we stick with a single macOS build in `.travis.yml`).

No longer output every cask under the list of changed formulae but
instead create a dedicated, unprinted report section for casks and then
iterate through that instead.

This reverts commit b33b1af0.

`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).