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.