Add support for C++20 modules

[mikomikotaishi]

This pull request adds support for C++20 modules, by enabling the macro BUILD_RAYLIB_CPP_MODULES at build time. It gives access to the module raylib, which is imported by writing import raylib;.

[mikomikotaishi]

@RobLoach Hi, are there any concerns regarding this PR before it could be merged?

[mikomikotaishi]

Also, I have a question about the library. Is there a particular reason you chose to continue use PascalCase for the methods/functions, rather than just camelCase? I know that in the original Raylib library the functions use PascalCase names, but besides that I feel like it is more difficult to distinguish function and class names if both are PascalCase. If that makes sense, would you considering allowing a build option using a preprocessor macro to toggle whether methods are PascalCase or camelCase?

[RobLoach]

Thanks for pushing this forwards. Just hadn't had a look.

Is there a particular reason you chose to continue use PascalCase for the methods/functions, rather than just camelCase?

While I understand the C++ convention is usually camelCase, keeping them the same as raylib has a few benefits...

1. Means there's no question what it should be in raylib-cpp
2. Makes porting from C to C++ easier as you don't have to consider the cases when porting

A preprocessor would be cool, but I'd fear it may result in a lot of maintenace issues. Could we have them be aliases or something so that the code could work in either case?

[mikomikotaishi]

Ah, sorry for my impatience.

As far as I'm aware there is no way to alias function names with the keyword using - only class names and variables/constants can be renamed. That being said, there'd only have to be one implementation, if we could put the preprocessor changes inside the function signature. That would look something like this:

// example of Color::ToInt()
#ifndef RAYLIBCPP_CAMEL_CASE
[[nodiscard]] int ToInt() const 
#else 
[[nodiscard]] int toInt() const
#endif
{ return ::ColorToInt(*this); }

etc.

Now I understand that won't be the most elegant thing in the world, and would probably make the code look a lot harder to read, but it's the only thing I can think of.

That being said we could rename all the methods by doing something like

#ifdef RAYLIBCPP_CAMEL_CASE
// ...
#define TO_INT toInt
// ...
#define TO_INT ToInt
#else

#endif

Also, getters and setters could also be affected by the presence of that macro if we altered the GETTER() and GETTERSETTER() macro accordingly.

[RobLoach]

I think keeping inline with the original raylib conventions may be best for the case. While changing it will make it feel more like C++, changing it will deviate from raylib, and break existing usage.