Fix infinite loop when importing 3D object named "-colonly"

[timothyqiu]

Fixes #83763

The set_owner() seems unnecessary to me. But it's called in other branches where p_node needs to be deleted and return null.

[akien-mga]

Seems ok to fix the infinite loop.

This whole code is still in dire need of a major refactoring. Here it should probably not at all handle nodes named -colonly as having a colonly hint.

[akien-mga]

Thanks!

[dc1248]

@akien-mga Are you sure the -colonly node should just be deleted? My impression is that the Blender file has a mesh object with a -colonly child object to be imported as a collision shape. I haven't used that convention but it seems sensible if Godot would allow it.

[akien-mga]

No, my point is that if a Blender object is just named -colonly, we should either:

• Consider that it doesn't respect the convention, and thus not apply the import hint. So whatever that object is in Blender would be added as a node in Godot named -colonly, without generating collisions.
• Consider that it respects the convention, and thus generate a new name for it, likely the default collision polygon node name.

Currently we do a third option which is skipping this node as invalid, with an error. That's also fine given that it's a corner case which is unlikely to happen frequently, and is easy to fix in Blender.

[dc1248]

Okay, fine with me if it prevents needless complexity and bugs. I just wanted to make sure we're not accidentally changing the behavior. I was thinking that nodes created by import hints don't need names because they come in with generated names like @StaticBody3D@19798 and @NavigationRegion3D@19797 as of ~4.1.

It would be nice if someone could actually document these conventions, maybe in the "warning" box on this page... https://docs.godotengine.org/en/latest/tutorials/assets_pipeline/importing_3d_scenes/node_type_customization.html