Add PropertyListHelper

[KoBeWi]

Follow-up to #83888 (partially)

This PR adds PropertyListHelper. It's a helper class for managing dynamic properties added with _get_property_list(). Initialize it with prefix, then register properties with name, default, setter and getter. Afterwards, instead of implementing _get_property_list(), _set() and _get(), just call a method in the helper and it handles everything for you. As a bonus it can also handle reverts.

I added it to ItemList. Property handling is now a bunch of one-liners, while the functionality has improved. Defaults no longer save in the scene and you can revert.

godot.windows.editor.dev.x86_64_1PxuOZSe6G.mp4

I will do a follow-up to apply it to all relevant classes (TileMap, PopupMenu and probably some others).

UPDATE
In the second commit I changed how properties are registered and the 2 implementations are different. idk which one is better.

Production edit: closes godotengine/godot-roadmap#14

[sairam4123]

Could it be exposed to scripting, I think this will be of good value if it could be exposed.

[KoBeWi]

Not in this PR, and that would likely require a proposal. It's easier to maintain a class if it's internal.

[YuriSizov]

Why is it in scene when its functionality relates to all objects, not just nodes? Although I guess we already have PropertyUtils in here as well.

[KoBeWi]

It's needed pretty much only for editing these objects in the inspector. scene is both nodes and resources, so I think it's fitting.

[YuriSizov]

This feels kind of awkward that some properties would now be "registered" in the constructor. I understand that this needs to happen per instance, but maybe we can figure out a way to register those dynamic indexed properties in ClassDB (so it works in _bind_methods) and resolve them dynamically?

[KoBeWi]

They could be added to ClassDB, but not sure how to resolve setters/getters then. I made them use callable_mp(), because it's faster than calling them by name, and it requires instance. Maybe there is a trick to fetch the method pointer from method name, but it would involve some core changes for registering and then assigning these properties to an instance. And that's for something that's basically only useful in the editor inspector, you can't even have them documented, because these properties can't be used without knowing their full name. IMO not worth it.

[YuriSizov]

IMO not worth it.

I think adding a third place to define properties is not a great idea. That makes classes harder to maintain. So anything we can do to avoid that is worth it, in my opinion.

[KoBeWi]

I added a static PropertyListHelper that registers properties and then instances are created for actual objects. It uses regular Callables though.

[groud]

I wonder if this is not a bit unnecessary. Considering that you have to implement _set, _get and _get_property_list anyway, it's clear that this it going to be dynamic. Having to create a static object, then create another object out of it is a bit complex IMO.

Maybe we should move the initialization to the constructor? Unless it hurts performance that seems like an acceptable solution.

Another solution would be to, like, find a way to define this object in _bind_methods? So that those stay close together?

[KoBeWi]

The old version (53ad7ea#diff-8cbdaea96117950192d3baac12f8cff87b2c4598e04e5df1aae4758f5de3b09b) was being initialized in the constructor, I changed it to static approach. It's definitely cheaper this way and it's closer to how we define the properties normally.

[akien-mga]

Thanks!