Splitting WindowsToolchain

[MarkSchofield]

"WindowsToolchain" started as - essentially - my home-grown, minimal build environment. I wanted the fast, cheaply authored, incremental build that CMake+Ninja gets, but for building Windows projects - that may include, say, CppWinRT/IDL/NuGet-like things. As a result, WindowsToolchain currently has two jobs:

1. It's a CMake Toolchain
2. It provides CMake conveniences and support for Windows build constructs that are often described in MSBuild scripts/SDK's/etc...

The project attempts to differentiate the two jobs by having the main toolchain, and then 'Support' files for opt-in things. But the "CMake Toolchain" job is better defined than the "CMake conveniences and support" job. The former should be stable, relatively unchanging with a minimal 'surface area'. The latter should be progressive and grow over time to keep-up with changes in Windows build constructs/tooling.

Based on these requirements and constraints I think it would be best to split the project in two. "WindowsToolchain" should be a minimally sufficient CMake Toolchain that is relatively unchanging. Folks bringing projects from, say, MacOS or Linux-based CMake builds should be able to have a consistent experience on Windows just by specifying the WindowsToolchain. Then the 'opt-in' pieces can move to a new project - say, "WindowsCMake" - that brings Windows build constructs (like CppWinRT/IDL/NuGet-like things) to a non-VS Generator CMake build.

I think this will bring stability and minimal 'surface area' to the WindowsToolchain to help fix #18 and #50 and decouple from churn in "WindowsCMake".

What do folks think?

[MarkSchofield]

https://github.com/MarkSchofield/WindowsCMake has been split off from https://github.com/MarkSchofield/WindowsToolchain