CMake + GCC module proof-of-concept

Hi all, CMake developer here. There's been a lot of noise and discussion of modules recently, particularly with respect to how build systems will deal with it. There has been build2 for quite a while, but it was also designed with modules in mind.

At Kona last week, I worked with Nathan Sidwell who is working on GCC's module support to get a minimally viable proof-of-concept for CMake building modules. There is ongoing discussion about the actual format of the information GCC writes out to communicate module dependency information to CMake, so that part certainly isn't final. I've created a Docker image with all the bits required to reproduce this setup locally as an existence proof that existing build tools can also do it (without magical implicit BMI-generation behind the scenes). There are some known limitations, but nothing that's an existential worry at the moment.

Currently this is using the strategy described in §6.2.1 there ("Scan sources independently then collate") because a scan tool smart enough for §6.2.2 doesn't exist right now (that strategy would likely be preferred on Windows due to process launch overhead costs).

Are imports discovered at configuration phase or as part of the build?

Right now, it's keyed on "are you using C++20" and "does the compiler support extracting module dep information". There will probably be a target property to say "nope, no modules here" to skip the extra build logic too. Note that header unit modules and external modules will almost certainly need some extra CMake code, but if patterns show up, the details can probably be hidden behind convenience APIs.