Generate docs from GDExtensions using --gdextension-docs with --doctool

[dsnopek]

Currently, --doctool won't generate docs for GDExtensions, only engine types.

This adds a new option (--gdextension-docs) which will generate docs only for GDExtensions used in the current project. It's intended to be paired with --doctool, similar to how the existing --gdscript-docs option works.

I'm not crazy about adding more stuff to main.cpp, but this is more-or-less in line with what we've already got there.

This is intended to be used with godot-cpp PR godotengine/godot-cpp#1374

[paddy-exe]

LGTM. The const could be added in the already specified section

[paddy-exe]

Just had a look at this again. Could this also be a const?
const String path = _doc_data_class_paths[i].path;?

[akien-mga]

It's pre-existing code (only indentation changed here), but yes it could be const.

[dsnopek]

This one actually can't be const because it's written to in the following two lines:

				if (path.is_relative_path()) {
					path = doc_tool_path.path_join(path);
				}

However, the name variable the next line down, could be const, I think. That said, since this PR is just indenting this, I'd prefer to leave the code in this block as is.

[akien-mga]

Tested and it works great! See godotengine/godot-cpp#1374 (comment) for details.

Might be worth addressing the issue with the XML schema URI in this PR too while we're at it.
Or not, depending on the solution we go for. E.g. we could make it an absolute URL for all XML regardless of whether they're core APIs, modules, or extensions. This would affect all XML files so best kept for another PR.
But if we prefer to just special case extension XMLs like modules are already handled in DocTools::save_classes, this could be done here.

[dsnopek]

@paddy-exe @akien-mga @m4gr3d Thanks for the review!

Might be worth addressing the issue with the XML schema URI in this PR too while we're at it.
Or not, depending on the solution we go for. E.g. we could make it an absolute URL for all XML regardless of whether they're core APIs, modules, or extensions. This would affect all XML files so best kept for another PR.
But if we prefer to just special case extension XMLs like modules are already handled in DocTools::save_classes, this could be done here.

In my latest push, I added a possible solution for the XML schema URI issue. It adds a new argument (p_use_relative_schema) to DocTools::save_classes(), which will either use the current relative schema, or the absolute URL. This should be OK, since we haven't exposed DocTools::save_classes() and only use it from main.cpp.

Actually, it looks like the only place we use the p_include_xml_schema argument to DocTools::save_classes() is when generating GDScript docs (via --gdscript-docs). Maybe we could replace that argument with the p_use_relative_schema argument, and then use the absolute URL for both GDExtension and GDScript? That would be more consistent...

[dsnopek]

Actually, it looks like the only place we use the p_include_xml_schema argument to DocTools::save_classes() is when generating GDScript docs (via --gdscript-docs). Maybe we could replace that argument with the p_use_relative_schema argument, and then use the absolute URL for both GDExtension and GDScript? That would be more consistent...

I've gone ahead and switched to doing it this way in my latest push.

It looks like I'm the one who added the p_include_xml_schema argument anyway (in PR #76490), so I can be the one to replace it with something a little better as well. :-)

[akien-mga]

Thanks!