Add C++20 module build target v2

[Gaspard--]

This is a cleaner attempt at #1364 which hopefully is more maintainable and approchable.
While #1364 tried to tag each symbol, this PR tags namespaces instead, reducing the amount of defines that need to be inserted.

Usage in client cmake:

set(FLECS_M0DULE ON CACHE BOOL "Build flecs module" FORCE)
add_subdirectory(path/to/flecs)
target_compile_features(flecs-module PUBLIC cxx_std_23)
target_link_libraries(
   someProjectName
   PRIVATE
   flecs-module
)

In the code, it is then possible to use import flecs; to import all the flecs symbols. The current version includes everything in the flecs namespace, but avoids including anything in the _ namespace.

Maintainance:

• namespaces that contain symbols to exported must be tagged with FLECS_API_NAMESPACE
• namespaces that should be excluded should be seperate in order to avoid exporting symbols
• static globals must be tagged with FLECS_STATIC_IN_HEADER, which becomes static in headers, but not in the module
• some rare symbols outside namesapces are necessary for compilation, such as operator new / delete, and must be tagged FLECS_API_DEPENDENCY

I'd ideally like to find a way to modify the tests to import flecs instead of including it, but I don't know enough about bake to know if it's even possible (which seems unlikely if bake only works with includes).

[SanderMertens]

This is a huge change which adds more complexity to the already non-trivial symbol exporting options of Flecs. When discussed on Discord you mentioned that besides being able to do

import flecs;

instead of

#include "flecs.h"

there aren't many benefits. Are there other benefits that are worth taking into account? Otherwise I'm not sure if the size/complexity of the change (and the maintenance effort going forward) balances out the pros.

[Gaspard--]

There is a compilation speed benefit which is the main reason to do this.
I'm fine with this not being merged, I'll try to update the branch from time to time for anyone that might want this.
While the changes may seem big, they're pretty "simple", so it's not too hard.
I think it's likely that request for module support might increase as adoption becomes more common, so someone might pick this up in the future.
Feel free to close this PR.