Replace NodePath properties with Nodes

[TechnoPorg]

Since godotengine/godot#62185, we have the ability to export Node types as properties in the editor, rather than just NodePaths. which simplifies the need for code that gets an actual Node from the path.
However, there are a few properties of built-in engine classes that still use NodePaths to provide access to a Node object; for example, RemoteTransform3D.remote_path. This feels unnecessarily clunky, since Nodes are used more often than NodePaths, resulting in extra conversions when working with the latter.
Additionally, with a direct export of a Node type, the specific type of Node could be specified (Node2D, Node3D, etc.), whereas with NodePaths, a path to an incompatible type of node could be given; for example, with RemoteTransform3D, giving a path to a Node2D.

[aXu-AP]

Good, idea, I wonder if it's too late, too big change for Godot 4? For some cases nodepaths actually make more sense, for example in animation, where all track paths are relative to root and also point to properties.

I made a list of properties and methods that use nodepaths to pass references to nodes. I tried to filter out any instances where paths are relative or make more sense otherwise. Comment if you find something I missed or if this list contains properties/methods where nodepath should remain.

AnimationPlayer: root_node
AnimationTree: anim_player, advance_expression_base_node
Area3D: wind_source_path
BoneAttachment3D: get_external_skeleton(), set_external_skeleton()
Control: get_focus_neighbor(), set_focus_neighbor(), focus_neighbor_bottom, focus_neighbor_left, focus_neighbor_right, focus_neighbor_top, focus_next, focus_previous
GPUParticles2D: sub_emitter
GPUParticles3D: sub_emitter
ImporterMeshInstance3D: skeleton_path
Joint2D: node_a, node_b
Joint3D: node_a, node_b
LightmapGIData: add_user(), get_user_path()
MeshInstance3D: skeleton
Node3D: visibility_parent
PhysicalBone2D: bone2d_nodepath
Polygon2D: add_bone(), get_bone_path(), set_bone_path(), skeleton
RemoteTransform2D: remote_path
RemoteTransform3D: remote_path
RootMotionView: animation_path
SceneTree: get_multiplayer(), set_multiplayer()
SkeletonIK3D: target_node
SkeletonModification2DCCDIK: get_ccdik_joint_bone2d_node(), set_ccdik_joint_bone2d_node(), target_nodepath, tip_nodepath
SkeletonModification2DFABRIK: get_fabrik_joint_bone2d_node(), set_fabrik_joint_bone2d_node(), target_nodepath
SkeletonModification2DJiggle: get_jiggle_joint_bone2d_node(), set_jiggle_joint_bone2d_node(), target_nodepath
SkeletonModification2DLookAt: bone2d_node, target_nodepath
SkeletonModification2DPhysicalBones: get_physical_bone_node(), set_physical_bone_node()
SkeletonModification2DTwoBoneIK: get_joint_one_bone2d_node(), get_joint_two_bone2d_node(), set_joint_one_bone2d_node(), set_joint_two_bone2d_node(), target_nodepath
SkeletonModification3DCCDIK: target_nodepath, tip_nodepath
SkeletonModification3DFABRIK: get_fabrik_joint_tip_node(), set_fabrik_joint_tip_node(), target_nodepath
SkeletonModification3DJiggle: target_nodepath
SkeletonModification3DLookAt: target_nodepath
SkeletonModification3DTwoBoneIK: get_pole_node(), get_tip_node(), set_pole_node(), set_tip_node(), target_nodepath
SoftBody3D: set_point_pinned(), parent_collision_ignore
ViewportTexture: viewport_path
VisibleOnScreenEnabler2D: enable_node_path
VisibleOnScreenEnabler3D: enable_node_path

As a side note, there's inconsistency whether property names end with _path, _nodepath, _node or no suffix at all. One other thing this would set straight. I'd use convention where no suffix is added, unless it's needed to differentiate from other properties. In that case, use _node. I also would rename some properties to target where node's main purpose is to affect some other node, for example VisibleOnScreenEnabler3D.enable_node_path or RemoteTransform.remote_path.