Clean-up editor plugins and class registration

[dsnopek]

This started because I wanted to do something from an EditorPlugin that wasn't specific to a single vendor, and realized that we don't have a common EditorPlugin, we've got one for each vendor.

It makes sense that we have an EditorExportPlugin for each vendor (to keep the logic for each self-contained), but they don't each need an EditorPlugin. I think this is just left over from when we did separate C++ builds for each vendor.

Then things snowballed into a number of clean-ups associated with the editor plugins and class registration :-)

Here's all the changes in this PR:

• Consolidate on a single OpenXRVendorsEditorPlugin that registers all the EditorExportPlugins
• Rename the OpenXREditorExportPlugin base class to OpenXRVendorsEditorExportPlugin to match
• Register all of our editor-only classes as "internal classes" using GDREGISTER_INTERNAL_CLASS()
• Update all other class registrations to use the GDREGISTER_CLASS() macro, since the macros are the recommended API, over calling ClassDB::register_class()
• Remove the docs XML for all the classes that are now internal - they are hidden from users and so docs aren't needed

[BastiaanOlij]

Not sure if I'm misreading things, generally agree with the improvement but it seems the lynx export setup has gone missing.

Or is this because there is nothing to override in the lynx version of the export settings (seeing we currently don't have settings?). In that case I would still suggest we have a class but without any further methods in it just to keep the structure in tact. It's likely that in the future we will need to add settings here as Lynx usage increases, it will be more clear for people who wish to contribute those changes to submit PRs if they can see where the changes are expected.

[BastiaanOlij]

Also, and I may be getting ahead of myself, seeing what we're planning with godotengine/godot#106891, should we rename the Khronos export to HTC export as it really only implements the HTC bits? Or just split that off into a separate HTC class (something I had a PR up for at some point in time I think), and then mark the Khronos export as deprecated.

Might be too early to consider that though but throwing it out there :)

[dsnopek]

Not sure if I'm misreading things, generally agree with the improvement but it seems the lynx export setup has gone missing.

Yeah, it never had its own EditorExportPlugin. I can add an empty one that just descends from the parent class and sets the name though!

Also, and I may be getting ahead of myself, seeing what we're planning with godotengine/godot#106891, should we rename the Khronos export to HTC export as it really only implements the HTC bits?

We could! But that's not really related to the rest of the clean up I'm doing here.

[dsnopek]

My latest push adds a new EditorExportPlugin for Lynx

Renaming the Khronos plugin to HTC does make sense. Especially now that lots of the vendors here actually use the Khronos loader, we should probably be thinking in terms of vendors, and not loaders. But I guess that'll need some more discussion

[BastiaanOlij]

Looks good, definitely makes things more manageable!

Agree that we should talk some more about splitting HTC into its own option and do that in a separate PR.