Re-add Skeleton3D::animate_physical_bones property and Skeleton3D::bone_pose_updated signal

[raulsntos]

Tested versions

• Reproducible in v4.3.dev.mono.custom_build [2efbc6b]

System information

Pop OS 21.04

Issue description

As I was looking into the compat break in 4.3 for the migration guide (godotengine/godot-docs#9250) I found these changes in Skeleton3D that look like they could be avoided.

The property animate_physical_bones:

• It was removed in Implement a base class SkeletonModifier3D as refactoring for nodes that may modify Skeleton3D #87888.
• The methods set_animate_physical_bones and get_animate_physical_bones are still available, so they could be used to re-expose the property.

The signal bone_pose_updated:

• It was replaced by skeleton_updated in Remove bone_pose_updated signal and replace it with the skeleton_updated signal #90575.
• We could re-add the old signal and emit it when pose_updated is emitted which seems to be the suggested alternative, so existing user code still works.

Steps to reproduce

Try to use any of the mentioned members in GDScript or C#.

Minimal reproduction project (MRP)

N/A

[TokageItLab]

bone_pose_updated is quite dangerous and cannot be re-added in the same way as in the past, as it cannot be guaranteed to work in the future. For example, this could be called a lot in the Deffered process, but it could become an obstacle in the future when we support multi-threading, etc. So I think it could be added as an alias for skeleton_updated.

animate_physical_bones is based on the state of Skeleton3D's internal objects (SkeletonSimulator3D) and needs to sync, so this cannot be added in the same way as before. I think it is possible to bind it in a state that is not exposed to the editor and is not serialized. (If there are no problems testing for regression of #93504, we may be possible to serialize it.)

[raulsntos]

Sounds good. As long as the methods exist to prevent breaking binary compatibility, and the behavioral changes are kept to a minimum and are well documented I think that's fine.

[dsnopek]

I think it is possible to bind it in a state that is not exposed to the editor and is not serialized.

Yes, this would be PROPERTY_USAGE_NONE passed to PropertyInfo() when registering the property