Add a Windows.EWDK.toolchain.cmake

[MarkSchofield]

As @kaloth called out in #74, using WindowsToolchain from an Enterprise WDK environment is a bit tricky. That review - I think - got the minimal fixes in to make it possible, this is a rough PR to get a better solution in place. There's work still to do:

• [x] This includes fixes for the Windows.MSVC.toolchain.cmake file that I'll break-off, send separately, and then resolve this branch against.
• [x] Documentation needs to be written.
• [ ] ~Ideally, some tests would be added. Unfortunately, the GitHub Actions images don't include the EWDK, so if I want to add tests, then I'll need to download the 16GB ISO, figure out how to mount it, and then run some builds. That sounds a bit tricky and slow.~ Not in scope - see my comment; GitHub runners only have 14 GB of space, which is too small to download the 16 GB EWDK iso.

Feedback on the code and above points is welcomed!

---

This PR adds the "Windows.EWDK.toolchain.cmake" file to make CMake builds with the EWDK easier - converting EWDK-initialized environment variables to CMake properties to then use "Windows.MSVC.toolchain.cmake"

[kaloth]

This is looking good. I'll have a go at using it and report back.

[MarkSchofield]

Well, it looks like this can't be validated by a GitHub action - the 'About GitHub-hosted runners' page calls out that the runners only have 14GB of SSD space, which is too small to download the EWDK iso to. Due diligence validation on this toolchain looks like it would have to be manual. Perhaps it could be scripted for semi-automated local validation...? I feel a little bad to have folks pull 16GB iso's down.

[kaloth]

I've checked the change locally and it's working nicely on my system (Win10 running on QEMU KVM).

It's a pain that we can't validate it on GitHub, especially as their existing images already have VS installed. Maybe they'd be open to making a new base image without VS that then gives us enough space for the EWDK? Probably a long shot.

[kaloth]

BTW, I like having this as an additional toolchain file. It makes it nicely explicit and opt-in without the chance of someone accidentally using parts of it when they didn't mean to.

[MarkSchofield]

BTW, I like having this as an additional toolchain file. It makes it nicely explicit and opt-in without the chance of someone accidentally using parts of it when they didn't mean to.

Yeah, I think it encapsulates things well, and makes it really clear which environment variables are being used. Thanks for trying it out.