Refactor how the MSVC toolchain searches for a compatibility version.

Refactor how the MSVC toolchain searches for a compatibility version.

Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.

This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.

There are a few things you might want to watch for for specifically:

 - On all platforms, if MSVC compatibility flags are provided (and valid), use
   those.
 - The fallback sequence should be the same as before, but is now consolidated
   into MSVCToolChain::getMSVCVersion:
   - Otherwise, try to use the Triple.
   - Otherwise, on Windows, check the executable.
   - Otherwise, on Windows or with --fms-extensions, default to 18.
   - Otherwise, we can't determine the version.
 - MSVCToolChain::ComputeEffectiveTriple no longer calls the base
   ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
   Windows the architecture, which we don't care about for the compatibility
   version.
    - I'm not sure whether this is philosophically correct (but it should
      be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
    - Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
      like the effective triple was always being used previously anyhow.

Reviewers: hans, compnerd, llvm-commits, rnk

Subscribers: amccarth

Differential Revision: https://reviews.llvm.org/D27477

llvm-svn: 288998