Change the way GLTFDocumentExtension classes are registered

[aaronfranke]

This PR changes the way GLTFDocumentExtension classes are registered. Previously the single extension was registered in GLTFDocument's constructor, which is not a good approach. This PR allows using GLTFDocumentExtension from GDScript or GDExtension unlike the old approach which only worked well for code directly in core.

There is now a static Vector all_document_extensions, and there is a method to add to this. This allows registering GLTFDocumentExtensions that can be used. Whether a GLTFDocumentExtension is actually used for a particular file import depends on the result of import_preflight, if it returns an error then the document extension will not be used (if it returns OK, it will be used, and we add the document extension to a non-static Vector per each instance of GLTFDocument).

All GLTFDocumentExtension classes are assumed to be stateless.

This work was sponsored by The Mirror.

[fire]

We designed this in conversation in discord. Will review. Maybe @lyuma

[fire]

We had further review with @lyuma and @aaronfranke today.

Decisions discussed in newest order first.

1. GLTFDocumentExtension should return a list of extensions implemented
   and then the base importer can check that all required extensions were properly implemented
2. Well right now the method returns an Error code.
   We could make it so that if import_preflight returns an error code then we don't enable it.
3. state->json["extensions"] should be state->json["extensionsUsed"]
4. iirc GLTFState only has the "generated" GLTF path, not the original file's. Discussed. iFire mentioned that glb buffers don't have paths.
5. move out the first commit the lights and n
6. Memory hazy..

[aaronfranke]

1. Is done, the method is called get_supported_extensions, it's in the last commit. EDIT: This part was merged in GLTF: Store extensions in GLTFState and get supported extensions from GLTFDocumentExtension #66094
2. Is done, if import_preflight returns an error code the extension will not be used. Same with export_preflight.
3. Is taken care of, I ensured that extensionsUsed is used everywhere it's supposed to.
4. Is not a part of this PR.
5. Is done, the PR is Minor enhancements to the GLTF module (lights and docs) #66087 (this is actually merged but GitHub bugged out and it broke)
6. I hope your memory becomes less hazy :)

EDIT: I also opened #66094 which is another subset of this PR.

[fire]

The starting message is now out of date and the pr needs rebase. Working on #66094

[fire]

I wasn't able to work on this this weekend. I'll see if I can get someone from our group to check.

[fire]

Thanks for splitting. It makes review better.

[fire]

We devised this way to implement the two lists of extensions. Active vs all.

[lyuma]

I won't be the one to block this review over this since I'm not familiar enough with the usage of C++ elsewhere, but I would like to warn you against the use of a static Vector.

__static_initialization_and_destruction is not something I like to deal with. Prepare for Unforseen Consequences.

The Godot pattern that I would suggest to use is to have a GLTFExtensionRegistry singleton, which is initialized in module init and destructed in module uninit, avoiding the use of complex static objects.

[fire]

@lyuma 's method is more robust. Can you investigate @aaronfranke ?

[aaronfranke]

@fire @lyuma I'm not familiar enough with that to be confident in any changes. If there is a better approach I'd want feedback from a core Godot dev like @reduz or @akien-mga before I do potentially unnecessary work that I'm unfamiliar with. Also,static Vector works fine in this PR, so we could merge as-is and it could be modified further in a future PR.

[fire]

I apologize for the delay, it's on reduz's review list.

[fire]

I think this is good. We've waited an extended period and reduced the scope.

[akien-mga]

Thanks!