Use bound theme properties for documentation

[YuriSizov]

Based on #81551 (so drafting for now).

This PR makes use of the new theme item binding information for documentation generation. This means that the decision which properties to document no longer comes from what is defined with the default engine theme. Instead, just like with properties and methods, only what's registered by the class itself (and it's inherited classes) is added.

As a result, a couple of theme properties were removed since they aren't actually used by their respective classes (maybe they should, but for now they aren't, so removing them is a better option).

One open question is what to do with inherited theme properties. Historically, due to our reliance on the default theme, all inherited properties would be displayed in extending classes as if their own. This is handy, since you can always see every property that can affect the GUI node, but that's not how we do the docs for class members, signals, and methods. We can, now, filter these out and remove them from extending classes or add them as stubs without descriptions like we do for "overridden" class members.

For now I'm going with adding them everywhere. This is most consistent with our current documentation, for better or worse. We can reconsider this in a future PR, I think.

PS. Similar PRs will be made for theme overrides, code completion, and the theme editor. Going one by one to slowly figure out if anything is missing from the API (like this PR added data types to the bind information).

[KoBeWi]

I think displaying every inherited theme property is counter-productive. The documentation ends up with tens of new useless (and empty!) items. I'm not even sure if all of them are functional (some are though, I checked). I think it's better if they did not appear at all, like regular member, and in rare cases when the item's usage differ, it can be noted in the class description (I can only think of ColorPickerButton, which hides most of stuff).

Also entries that got removed should be removed from default theme too I think.

[YuriSizov]

Also entries that got removed should be removed from default theme too I think.

Did I miss any? I removed them from both the default theme and the editor theme.

[KoBeWi]

No, I missed your theme changes 🤦‍♂️

[akien-mga]

One open question is what to do with inherited theme properties. Historically, due to our reliance on the default theme, all inherited properties would be displayed in extending classes as if their own. This is handy, since you can always see every property that can affect the GUI node, but that's not how we do the docs for class members, signals, and methods. We can, now, filter these out and remove them from extending classes or add them as stubs without descriptions like we do for "overridden" class members.

I think being consistent with regular properties, etc. would be good. The big problem with duplicating them everywhere is that we need to duplicate their documentation everywhere too. So I'd prefer they're documented only in the base class (and overrides are shown like we do for properties).

If we still want a way to easily give an overview over all the theme properties a given class has access to, that's an orthogonal UX problem IMO, we can figure out solutions that don't require duplicating the XML and documentation data. (E.g. a folded-by-default list of all theme properties, below the list of theme properties added in this class and their documentation.)

[YuriSizov]

Alright, I removed inherited properties from documentation and unified some descriptions for H/V nodes. Inspector still works correctly and shows descriptions and redirects to correct pages. So I think we're good to go.

[akien-mga]

You need to copy back the descriptions to the base classes where the theme properties are now being exposed. We seem to be losing quite a bit of documentation otherwise.

[KoBeWi]

The "new" empty items are properties that weren't documented before and they never had description. The descriptions in inherited classes were copy-paste from the base class (with some changed references).

[YuriSizov]

Yes, I copied stuff that was only defined in extending classes or had differences not reflected in the parent class (like H/V variants). Maybe I missed some? But most of the descriptions that are now gone are duplicates of the base class documentation, as @KoBeWi says. Like in the case of a dozen Button types.

Edit: The only thing that we may be losing is default values which override inherited values of some properties. I'm not sure how useful this is for theme items, it's not really something that you reference. But if we want it, it will require the whole "overrides" logic that we use for regular class members.

[KoBeWi]

Looks fine, but I left some comments for theme item descriptions that you could copy from the deleted ones.

[YuriSizov]

Added missed descriptions, and modified ThemeDB::get_class_own_items so inherited properties which are cached by extending classes are also properly ignored. This removed a bunch more theme items. I added missing descriptions resulting from that too.

[akien-mga]

Thanks!