C++20 named module interfaces

Resolves #8358.

This is a repeat of this comment:

I want to state up-front that this was AI-generated, but verified manually; this prose is also manually written by me. I decided to go this route after having good provenance and priors in Vulkan-Hpp. I deemed a lot of the work highly manual, repetitive, and error-prone, which made sense to automate to some degree, at least.

The gist is straightforward:

1. The headers represent the public interface of imgui, and is included unconditionally in the corresponding module interface
2. The .cpp files are the implementations, which are in the private module fragment, denoted by module :private;
3. To allow for macro and include safety, transitive includes are blocked by a macro that says "we are in the module purview", that is, IMGUI_CXX_MODULE, and these headers are reproduced in each module interface unit.
4. Every symbol that needs to be exported is marked by IMGUI_EXPORT, a macro that expands to export when the above macro is itself active
5. Other macros have been gathered up into a 'macros header'. This should be available as usual with #include <imgui.h> for header users, but module users will need to write #include <imgui_macros.h> for access to macros.
6. Repeat for the back-ends, which themselves import imgui;. Note that some back-ends (especially for QNX and macOS/Metal/etc) haven't been ported. I am not sure of the interaction between Objective-C++ and C++20 modules.

This has been 'tested' (insofar as AI-generated testing counts...) locally, but I haven't really found a test suite online that I can adapt to verify that

1. The header-only mode continues to work seamlessly for those who want to use headers
2. The modules actually work

The change contains some miscellaneous CMake scaffolding, but this can be removed for the final work, and potentially integrate with #8896 or something else when that is ready.