Add support for C++ modules

[mikomikotaishi]

This PR adds support for C++ modules, which currently must be manually compiled (no CMakeLists.txt exists).

[tzcnt]

Per the discussions recently, in order to avoid diamond dependency issues when packaging for vcpkg/conan, I may be moving away from any precompilation, and making the entire library header-only.

Apologies for the noob questions - I haven't investigated modules at all, having spent all my time on coroutines and concepts instead. I've done some reading and it appears that modules offer a way to do the precompilation that's currently gated behind the TMC_IMPL macro, but in a more elegant fashion? If I just define a normal function as inline (necessary to prevent ODR violation in a header-only library), will modules prevent that from being recompiled in every translation unit, and instead provide a single compilation which can be reused?

What is the impact of P1498R1 and P1779R3 on this library? Is there a recommendation that I should make member functions inline or not-inline?

---

There is a typo on line 47: tmc::cpuexecutorl instead of ;, and AI identified 6 missing symbols:
aw_spawn_fork - type alias from spawn.hpp
aw_spawn_impl - class template from spawn.hpp
aw_spawn_func_fork - type alias from spawn_func.hpp
aw_spawn_many_each - type alias from spawn_many.hpp
aw_spawn_many_fork - type alias from spawn_many.hpp
spawn_clang - function from spawn.hpp
spawn_func_many - function from spawn_many.hpp

Is there a more reliable method to export all of the symbols necessary so that I don't have to remember to update this file while I'm adding a header?

In order to ensure that nothing else has been missed, mind forking the examples repo and adding a module build option there? To test there, git clone --recurse-submodules https://github.com/tzcnt/tmc-examples and then define the CMake option TMC_AS_SUBMODULE which will let you work with your fork from the ./submodules/TooManyCooks directory.

[mikomikotaishi]

Fixed the missing symbols and decided to alphabetise the using statements. I'll respond to the rest of these later

[mikomikotaishi]

Okay, so as you are probably aware, one notable advantage of modules is that modular translation units are compiled once and importing that module will just get its compiled interface, unlike #include which re-compiles the header each time it is used.

I believe that modules do not make all functions non-recompiled, but importers only have to compile against the already built module interface to get its definitions. Also, in modules, member functions are not implicitly inline, so you can define functions in the module interface without worrying about ODR semantics.

[mikomikotaishi]

@tzcnt Hi, is there anything else you want me to answer?

[tzcnt]

I won't merge without compiling the full examples suite and tests using the module API. That's why I requested you open a PR into the examples repo.

Otherwise I'll do it myself after I work through removing the IMPL macro requirement and review the package manager PRs

[mikomikotaishi]

compiling the full examples suite and tests using the module API.

Do you want me to duplicate all of the tests or do you want me to make it conditional on whether #include or import is used?