Making godot-cpp scons more idiomatic

### Godot version

4.4 (master)

### godot-cpp version

4.4 (c20a84e483ec61c77e5903cb4a139f6875e28a3b)

### System information

macOS

### Issue description

> Can you explain in more detail the problem you were having?

I've been having a bit of friction with how godot-cpp and its dependents (i.e. our recommended setup [godot-cpp-template](https://github.com/godotengine/godot-cpp-template)) interact. Specifically, I've been running into several problems trying to get a structure better structure for [my SConstruct](https://github.com/Ivorforce/NumDot/blob/main/SConstruct) (and subsequently, contributing the changes to godot-cpp-template). It's a WIP.

I've found the [SCons documentation](https://scons.org/doc/production/HTML/scons-user.html) not to be exhaustive, but I've been talking to SCons maintainers on Discord, who have been incredibly helpful in filling my missing pieces of knowledge.

Here's my latest gripe.

### Custom options

When a godot-cpp dependent defines a new config option, godot-cpp complains about the new variable through these lines of code:

https://github.com/godotengine/godot-cpp/blob/c20a84e483ec61c77e5903cb4a139f6875e28a3b/SConstruct#L37-L41

This is because arguments persist in `ARGUMENTS`, and godot-cpp finds and does not recognize them. This is confusing to the CLI user. We could remove the argument check, but then it would also be gone from godot-cpp's standalone use. I think using its SConstruct for both standalone and dependants is a bit of a split of two different interests, and may lead to more issues like this. Not to mention, it could be worth it to work toward better compartmentalization to eventually support dependency chains linking against each other.

### Modularizing

SCons maintainers suggested not to use SConscript. SConscript is intented for sub-projects, rather than for dependencies (though arguably, godot-cpp is both). In their suggestion, godot-cppp's SConstruct would be used only to build it standalone, while its dependants would have their own SConstruct and call its tools explicitly. I do like this idea, because it favors modularity. Trying to implement it, however, I ran into several issues:

- toolpaths are wrong, because `toolpath` is relative to `pwd`, unless SConscript is used. This would be solvable by #1645.
- imports are wrong, because `godot-cpp` is not part of `sys.path`, unless SConscript is used. You can add `godot-cpp` to `sys.path`, but it's a bit awkward.
- source locations are wrong, because they are resolved relative to `pwd`, unless SConscript is used. This could be solved using `__file__` as a base, and add the cpp files as absolute paths.

Depending on your viewpoint, you could interpret this as either
- "godot-cpp makes too many assumptions about `pwd`, and should more agnostic, or state / adopt its assumptions more explicitly."
- "just use SConscript, that avoids all these problems."

Anyway, without making any judgement calls just yet, I opted to experiment more to see if godot-cpp could actually be compartmentalized into a toolchain. But I thought #1645 would be relatively uncontentional, since it merely adapts what is the tooling standard of SCons (I should note here that the authors were specifically confused as to why godot-cpp's tools were not in `site_tools` but rather elsewhere).