Clean up some cruft in the library path searching logic by making

Clean up some cruft in the library path searching logic by making
'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.

Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.

Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:

  /lib/../../lib32
  /usr/lib/../../lib32
  /usr/lib/x86_64-linux-gnu/../..lib32

Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.

I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.

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