Generate GDExtension interface header and loader from JSON

[dsnopek]

This is the first step towards "godot-cpp v10" as described in this proposal.

It does a bunch of things:

• Generates the gdextension_interface.h from gdextension_interface.json
• Replaces most of the code that loads the GDExtension interface functions with code also generated from gdextension_interface.json
• Adds a deprecated=no option for SCons to prevent loading deprecated GDExtension interface functions
• Puts the loaded functions under godot::gdextension_interface rather than godot::internal, making them officially part of the API
• Allows working with both Godot 4.5 or 4.6, depending on which version generated the extension_api.json
• Standardizes on using fully qualified namespaces for ::godot::gdextension_interface and ::godot::internal

There's one important thing this it does NOT do, which is cmake support for the build system changes. That's something I've still got to figure out.

Marking as DRAFT because it now depends on Godot PR godotengine/godot#113697

[dsnopek]

Hrm. MSVC is having issues with using interface as a namespace, but only when building with CMake? That's odd...

[dsnopek]

I ended up renaming interface to gdextension_interface, which I think I like better anyway :-)

[dsnopek]

Now that PR godotengine/godot#113697 is merged, I've updated it to match the latest in Godot master, and taken it out of DRAFT

[Yarwin]

why don't you return python's f"""string instead? Regexes are less readable, have no IDE support and might be error prone (i.e. four changes from now someone will make typo and it might slip unnoticed).

(that's not important for now thought, it is something that might be tackled as a follow-up task as a good first issue or something)

[Yarwin]

and IMO ret = "m_ret" if returns else "" might be easier to reason about than separate if/else blocks.

[dsnopek]

Perhaps! However:

1. That's something for a different PR. This code is only touched in this PR due to some renames that were search-and-replaced - the changes you describe would not be related to the high-level goals of this PR
2. This code was copied from make_virtuals.py in Godot itself and modified slightly. I don't want it to get too out-of-sync with the original, since we do periodically copy code back from Godot into godot-cpp. So, if we were to change this, ideally, we'd change it in both places

[Ivorforce]

The changes you list and the direction this PR works towards make sense to me.

The code is admittedly a little hard to review, since it's quite a lot of changes at once. I might have preferred some of the refactoring changes to be done later, but it's not a deal breaker.
I did go through all of the code and saw nothing that struck me as particularly worrisome. So it looks good to me!

What this needs is testing in at least 2 or 3 projects. I can provide some of that some other time.

Since this is a lot of core functionality changes, we might want to enter a "Beta phase" and add a disclaimer to README.md where we encourage people to use the minor version branches for production projects, since godot-cpp 10 is hot off the press.

[Ivorforce]

Why not evaluate the if at python time (rather than letting C++ figure it out)?
The advantage should be faster compile time.

[dsnopek]

What I like about this approach is that it resembles the code I would have written manually, and it's explicit why specific functions are missing. With the build_profile.json, we completely omit anything not included in the build profile, and we occasionally get support requests from folks asking why certain methods aren't exposed, when the answer is that there's a class in the arguments or return value that isn't included in their build_profile.json. So, this avoids that problem by leaving a trail in the source code.

(Unrelatedly, I'd love to leave some sort of trail in the code for the build_profile.json too, but we implemented that by filtering the API upfront, so we don't even know those methods exist when generating the code for the class, and can't drop in a comment or something.)

[dsnopek]

Thanks for the review!

The code is admittedly a little hard to review, since it's quite a lot of changes at once. I might have preferred some of the refactoring changes to be done later, but it's not a deal breaker.

Sorry about that! I hadn't originally intended to do so much in one PR, this was just supposed to be the v10 changes at first, but then I realized how much easier that would be based around gdextension_interface.json, so integrating that got pulled in as well.

Since this is a lot of core functionality changes, we might want to enter a "Beta phase" and add a disclaimer to README.md where we encourage people to use the minor version branches for production projects, since godot-cpp 10 is hot off the press.

That makes sense! We'll need to update the README.md soon anyway, since we'll need to alter the version compatibility information that's in there