If @compiler isn't set/checked by ENV.compiler and the ENV.clang/etc.
methods, ENV.compiler may return unexpected results after fails_with
picks a fallback compiler.

See Homebrew/homebrew#22674.

These methods were overriding CC and causing superenv to potentially
skip the compiler wrapper - especially if no wrapper existed for the
compiler being used, e.g. GNU GCCs.

Closes Homebrew/homebrew#22443.
Fixes Homebrew/homebrew#22249.
Fixes Homebrew/homebrew#22424.
Fixes Homebrew/homebrew#22506.
Fixes Homebrew/homebrew#22521.
Fixes Homebrew/versions#207.

This moves the CompilerSelector fails_with logic into the build
environment setup, making the compiler selection available before
performing actions that depends on knowing what the compiler is, e.g.
setting up PATH.

ENV.setup_build_environment now optionally takes a Formula argument
to provide the information necessary to do the fails_with, and the new
ENV.validate_cc! extracts the fails_with logic from Build.install.

This adds support for non-Apple GCC compilers in the fails_with code.
A fails_with block for a non-Apple compiler looks like:

fails_with :gcc => '4.8.1' do
  cause 'Foo'
end

Non-Apple compilers don't have build numbers, so compiler failures are
based on version strings instead.

Internally non-Apple compilers can be distinguished because they are
passed around as strings instead of symbols.

In addition, this alters the priority list for compilers, with the
following changes:

* Apple GCC 4.2 and LLVM-GCC swap positions, with GCC now taking
  priority. (Maybe LLVM-GCC should just go away.)
* Non-Apple GCC compilers are ranked below GCC 4.2 but above LLVM-GCC
  and Apple GCC 4.0.

See Homebrew/homebrew#21720.

This unifies the logic for selecting a compiler between superenv and
stdenv. A variation of superenv's `determine_cc`, which now returns a
symbol, has been moved into the shared ENV extension. Stdenv uses the
result of this directly (as it's always used symbols), while superenv
translates that back into a compiler string.

This also has the effect of disabling HOMEBREW_USE_(gcc|llvm|clang) in
stdenv, which have already been marked as deprecated for some time, and
enables the HOMEBREW_CC= environment variable syntax from superenv in
stdenv.

This allows overriding the "oldest CPU" behaviour - for instance, to
build Intel bottles for a newer CPU than Core 2, to build a PPC bottle
with or without Altivec on the same computer, etc.

Allows for building bottles on PPC both with and without Altivec.
This is currently not active but will be enabled once superenv is
stable on Leopard.

'gcc' could refer to anything of llvm-gcc, clang, or gcc-4.0 on
various Xcode versions.

On Unix, the path separator is ':', whereas on Windows,
it is ';'. This is the first of a series of patch to bring
macbrew's and winbrew's codebases closer together.

The main places the magic constant ':' was being used were:
  - the $PATH environment variable
  - CMAKE-related environment variables
  - pkg-config related environment variables

Closes Homebrew/homebrew#21921.

Signed-off-by: Jack Nagel <jacknagel@gmail.com>

We override ENV[] to always return strings under superenv, because
legacy formulae assume that CFLAGS, etc. are non-nil.

However, the current implementation has a bug. If I simply concatenate
ENV['CFLAGS'] with another string, it mutates ENV['CFLAGS']:

  irb> ENV['CFLAGS']
  => ""
  irb> ENV['CFLAGS'] + 'a'
  => "a"
  irb> ENV['CFLAGS']
  => "a"

Instead, let's simply return an empty string if the key doesn't exist.
This is sufficient because the following are equivalent:

  1. ENV['CFLAGS'] += "string"
  2. ENV['CFLAGS'] = ENV['CFLAGS'] + "string"

We want to be able to extend this module onto an arbitrary hash and use
it without mutating ENV, for testing purposes.

This defines the new HOMEBREW_ARCHS environment variable, which is
currently only set during universal builds, so that the tool wrappers
no longer need to hardcode i386/x86_64.