Build dependency system for classes

[Xrayez]

Some classes cannot be currently disabled without introducing yet another build option, like with the current LinkedList class.
Some classes also depend on functionality of other classes, like ListNode is essential for LinkedList, and must not be disabled.

Extensibility and customization are the core development principles behind Goost development, so we need to make sure that most functionality can be easily enabled or disabled at build-time.

In theory, the various classes implemented in nested modules/ may also depend on core/ functionality.

Note that the full list of classes is listed in the Goost API.

I propose introducing some kind of a dependency system to handle this at compile-time, which should be optional to use. The components system would be still relevant to conveniently enable or disable a collection of classes without accidentaly breaking dependencies.

A single manifest file could be created to configure what classes should be enabled or disabled in Goost. The dependencies themselves have to be explicitly declared in the existing root goost.py for each class if needed.

A manifest file can be written in Python, not JSON, as it would work better with the rest of the build system which is written in Python, in fact. The custom.py could be used for this purpose (#25), which is .gitignored currently. But it's also quite possible to introduce another manifest.py script.

Example manifest.py configuration file

# manifest.py

# All classes in Goost will be either enabled or disabled initially.
classes_enabled_by_default = "yes"

# If some classes are enabled by default, this will disable them.
classes_disabled = {
    "LinkedList",
    "ListNode",
    "ImageIndexed"
}
# If some classes are disabled by default, this will enable them.
classes_enabled = {
    "GDScriptTranspiler"
}

# NOTE: if a class is both declared as enabled and disabled at the same time,
# then `classes_disabled` takes higher priority.

There has to be a way to automagically disable compilation of classes according to a manifest. 🙂

The manifest=path/to/manifest.py should likely be added as a SCons option in the module's SCSub, because this is where component defines are generated.

SCsub

try:
    import manifest
	# Process the manifest here ...
except ImportError:
    pass

A similar approach at disabling all modules was also presented in godotengine/godot#41091.

See also godotengine/godot-proposals#1001.

[Xrayez]

Basic internal dependency system is implemented in #54.

The next step is to modify the build scripts so that sources of disabled classes are not compiled at all, which should speed up the build and optimize the resulting binary for size. For this to happen smoothly, the following must be done:

1. Being able to convert PascalCase to snake_case to map class names to source files. We need to make sure that each such source filename properly maps to class name, so may need to rename some files for that. See case conversion methods in https://github.com/Xrayez/gdgen/blob/master/gdgen/methods.py.
2. Remove sources of disabled classes. Ideally should work automagically somehow, since we have Python scripting in our disposal in SCons. Perhaps this can all be handled in module's SCSub without touching subdirectories at all.

[Xrayez]

This can be considered more or less feature-complete since #55.

I've figured that using macros alone is sufficient for this. Also decided that there's no need to follow a strict convention of UPPER_CASE for all Goost macros when it comes to naming classes, because combining UPPER_CASE + PascalCase makes it more readable and easier to maintain (lets say some classes may get renamed in the future, which happened to Godot 4.0).

I'd say it's also worth adding scons goost_manifest=/path/to/manifest.py build option at some point, but not high priority.

[Xrayez]

Also note that some sources will have to be eventually renamed to match the conversion.