Revisit `PropertyInfo` in public APIs

[Bromeon]

The PropertyInfo struct's purpose is 90% godot-rust internal type information, and 10% public API. As such, the latter has been neglected for the most part. Some public API examples:

• ParamTuple::property_info(index: usize, param_name: &str) -> Option<PropertyInfo>
• IObject::get_property_list() -> Vec<PropertyInfo>

There are several issues related to `PropertyInfo:

1. Some methods like property_sys(), empty_sys() should likely be private/hidden.

2. There are naming collisions between Object::get_property_list and IObject::get_property_list.

   • While Rust allows this, it can still be confusing. Godot solves this with the _ prefix.
   • We might want to rename some virtual methods to on_*, to make clear that they're the queried as a result of some public method call.
   • Similar for set/get vs. set_property/get_property -- something like on_set/on_get might be clearer.
   • Prior art: on_notification instead of Godot's _notification.

3. The struct itself is quite low-level.

   • This is probably OK if we recommend to use constructor new_var::<T>("property_name")
   • However, field class_id: ClassId cannot be set for non-class properties, as ClassId has no longer a public none() constructor.
     Either we provide this, or data model needs to change (e.g. more towards ElementType enum, without script?)

4. There is also MethodInfo, but it seems unused in public APIs?

5. EditorSetting::add_property_info() and ProjectSettings::add_property_info() take a hint but as dictionary.

   • Could a conversion, or directly type-safe method help here?

[kistz]

User feedback:
As someone who has used the property list api a lot i would also be in favor of the on_ prefix.
IMO it makes a lot of difference to parse it mentally at a glance :)

[TitanNano]

Regarding 3 and 4. Both PropertyInfo and MethodInfo are used by the script extensions. There it is actually also necessary to construct custom ClassId instances for the script classes, which is currently not possible with public APIs.

This has been a long-standing issue, but I haven't gotten around to raising or dealing with it.

[Bromeon]

Regarding 3 and 4. Both PropertyInfo and MethodInfo are used by the script extensions.

In public APIs? It doesn't show up in search, neither In Parameters (10) nor In Return Types (1).

---

There it is actually also necessary to construct custom ClassId instances for the script classes, which is currently not possible with public APIs.

ClassId::new_cached() is not enough for this case?

[TitanNano]

In public APIs? It doesn't show up in search, neither In Parameters (10) nor In Return Types (1).

Yeah, rust-docs search is not considering it inside generic type arguments: https://godot-rust.github.io/docs/gdext/master/godot/index.html?search=Vec%3CMethodInfo%3E

ClassId::new_cached() is not enough for this case?

New caches require a unique T: GodotClass but script classes won't have a Rust type. We probably have to make ClassId::new_dynamic public.