Make configure script respect (and save) values for `CC`, `CXX`, `CFLAGS`, etc.

I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.

The overall intention is to capture the following precedences for
guessing the C compiler:

 1. Value of `CC` at make invocation time.
 2. Value of `CC` at configure invocation time.
 3. Compiler inferred at configure invocation time (`gcc` or `clang`).

The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).

The `configure` script also does not attempt to infer the compiler if
`CC` is set; but if `--enable-clang` was passed, then it *does* still
attempt to validate that the clang version is compatible.

Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.

Fix #13805.
Some cleanup on respecting `CC`/`CXX`/`CFLAGS`/etc.

Address scenario where client passes --enable-clang while setting `CC`
to non-clang program (e.g. `CC=gcc`), by only checking clang version
if `CFG_CC` ends up looking like a variant of clang.

Fixed code to infer a `CFG_CXX` from the `CFG_CC` if necessary; we
were already doing this in an ad-hoc way in the part of the script
where we set up `LLVM_CXX`.  Doing it at the top-level let me cleanup
and generalize that code so that it handles values other than the four
fix cases that had been hard-coded earlier.

(It warns you if you try to use a compiler it didn't anticipate, but
makes a best effort to try to set up the options in a reasonable
manner even then.  It would be interesting to try to build against
`icc` with these changes.)

----

It seems likely that we could clean this code up further; in
particular I cannot tell why we are both adding `-m32` to the
`LLVM_CC_32`/`LLVM_CXX_32` and *also* to `LLVM_CFLAGS_32` and
`LLVM_CXXFLAGS_32` variables; the latter alone should suffice in
principle.
Address travis build failure by reverting commit 11d22debef.

As part of this PR, I am changing things so the that when we infer the
compiler settings it will assign `CFG_CLANG` to `CFG_CC`, and `CFG_CC`
to `LLVM_CC`.  But commit 11d22debef tries to assign `clang++` to
`CFG_CLANG`; LLVM does attempt to pass C code to the setting we
establish for `LLVM_CC`, and passing C code to `clang++` has been
deprecated (*).  That leads to build failures related to:

    clang: warning: treating 'c' input as 'c++' when in C++ mode,
                    this behavior is deprecated

So I am reverting things back so that if we are inferring a `CFG_CC`
setting, we will do so by probing for `clang`, not `clang++`.

Why this works: Back when commit 11d22debef landed, we did not even
attempt to configure `LLVM` ourselves, at least not from the configure
script.  But now the configure script is more ambitious and does
attempt to configure LLVM on the user's behalf: so any problems with
the `CXX` setting should be exposed during that step anyway, making
probing for `clang++` itself unnecessary (hopefully).

(Another reasonable option would be to probe for both `clang++` and
`clang` and then assign only the latter to `CFG_CC`.  But this seemed
simpler, since I do not think we ourselves use `clang++` anywhere; I
believe it is just for compiling LLVM.)

----

(*) Footnote: It seems that our configure script has avoided this
issue thus far by not actually using the value of `CFG_CLANG` itself
for `LLVM_CC`, and instead setting it to `clang` or `ccache clang`.
So our configure script would probe for `clang++` on your path (and
register that in the config.mk), but you would still need to
separately ensure that `clang` was also available on your path.  And
of course the value you have for `CC` itself was irrelvant, which is
what this PR is trying to fix.
auto merge of #13823 : pnkfelix/rust/fsk-fix-13805, r=alexcrichton

Make configure script respect (and save) values for `CC`, `CXX`, `CFLAGS` etc.

I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.

The overall intention is to capture the following precedences for
guessing the C compiler:

 1. Value of `CC` at `make` invocation time.
 2. Value of `CC` at `configure` invocation time.
 3. Compiler inferred at configure invocation time (`gcc` or `clang`).

The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).

The `configure` script also does not attempt to infer the compiler if
`CC` is set; but if `--enable-clang` was passed, then it *does* still
attempt to validate that the clang version is compatible.

Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.

Fix #13805.