Allow to customize C++ module name by not relying on module's directory name

[Xrayez]

Describe the project you are working on:
Various community C++ modules for Godot Engine, also https://github.com/goostengine/goost.

Describe the problem or limitation you are having in your project:
A lot of projects at GitHub have a convention of prepending godot- to the repository names related to Godot Engine. This is alright for most projects, but when it comes to C++ modules development, this is where the real problem kicks in. To name a few:

• https://github.com/Zylann/godot_voxel
• https://github.com/rakai93/godot_voronoi
• https://github.com/Xrayez/godot-anl
• Scons error when compiling for Windows bruvzg/webview_module#1

The build system in Godot detects C++ modules at build-time and infers module names directly from directory base names where these modules are located. Those exact directory names are then taken to generate various headers which hardcode various registering callbacks such as register_*_types to be included in register_modules_types() for each detected module.

Now, if you take these two facts, they don't play together, because:

1. When someone clones a repository, it's likely that a module might be cloned as-is, for instance:

# This is going to be cloned under `godot-anl` directory by default...
git clone https://github.com/Xrayez/godot-anl

2. While the build system can still successfully infer the name, it cannot change the code which was written to expect the particular module name in register_types.h/cpp sources.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I propose to add an ability to customize the module names via config.py::get_name(), instead of relying on directory names.

This also alleviates a possible problem which may arise in the future, mainly when different modules could have the same directory names (when using custom_modules build option which can specify a list of different directories where modules can be found). For instance, I may have a game module (#565.), but someone implemented a similar module in their own project which I want to reuse. This could result in module shadowing in the best case (which is a feature btw, if you now what you're doing), and build error in the worst case.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
The first thing which can be done is to fetch the module name explicitly via config.py::get_name(). If such method doesn't exists, the build system shall still infer the name from the directory name. That way, the build system will not rely on directory name, which would solve the issue, C++ modules developers would have to actually define config.py::get_name() themselves:

def get_name():
    return "anl"

If this enhancement will not be used often, can it be worked around with a few lines of script?:
You have to constantly remind people that they must rename the module directory name in order to successfully compile a module. In fact, I've even written some documentation in Goost which reflects this limitation.

This is how it should be done currently:

# Cloning properly:
git clone https://github.com/Xrayez/godot-anl anl
# Adding as submodule in another git project:
git submodule add --name anl https://github.com/Xrayez/godot-anl modules/anl

Yet some people go as far as to just fork a module and modify those names directly in their forks...

Some modules better follow the previously mentioned naming convention because:

1. It doesn't make sense to give a different repository name in case a module simply acts as a wrapper for another C++ library adapted to work with Godot types.
2. Do not want to create confusion with other large projects, as may be the case in https://github.com/GodotExplorer/ECMAScript, for instance.

Is there a reason why this should be core and not an add-on in the asset library?:
Have to modify the build system itself so the rest of the community can benefit from this.

I can implement this myself, having previously worked on custom_modules support in godotengine/godot#36922.