[cmake] Teach the Clang CMake build to use LLVM_LIBDIR_SUFFIX for its
'lib' directories in the build. This variable is available now both as
part of the normal LLVM build an as part of a standalone build as I've
added it to the LLVMConfig.cmake output.

With this change we should at least put libraries into the multilib
directory correctly. It is the first step in getting Clang to be
reasonably multilib aware.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@224923 91177308-0d34-0410-b5e6-96231b3b80d8
[multilib] Teach Clang's code about multilib by threading
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.

Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.

This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.

I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.

Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.

git-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@224924 91177308-0d34-0410-b5e6-96231b3b80d8