Disallow selection of ownerless nodes

[SaracenOne]

Closes #92187

This changes the behaviour of node selection when selecting ownerless nodes in the 3D node editor. Now, instead of simply selecting the ownerless node, it will walk its parents and attempt to find the first node which is valid for selection.

[ryevdokimov]

I agree that having nothing shown as selected in the SceneTree is confusing, but maybe an alternative is to show some kind transient node selection that is denoted somehow (like yellow being nodes owned by another scene in the case of inherited scenes). My concern now is that you can't access and modify the ownerless nodes properties in the inspector, which might be desirable in some circumstance.

[SaracenOne]

It's possible there is use for it, but looking everything which is generally considered standard operation in Godot, I really can't think of what that might be, and as pointed out in the issue, the current behaviour directly conflicts with a otherwise perfectly viable data-driven workflow. If the goal was to provide something similar with the behaviour of instanced scenes with the editable scene flag, I think at the very least there would be a requirement to flag an ownerless node as editable too before it can be selected.

[KoBeWi]

This is consistent with 2D editor. The equivalent code is here:

godot/editor/plugins/canvas_item_editor_plugin.cpp

Lines 706 to 710 in 8e2141e

	if (p_node != scene && !p_node->get_owner()) {
	return;
	}
	bool editable = p_node == scene || p_node->get_owner() == scene || p_node == scene->get_deepest_editable_node(p_node);

[caimantilla]

Aaah, I thought I was going crazy the other day! This happens with my spawner class, which instantiates the character scene to different positions for preview (orientation, entrance origin, destination, etc.)
Very keen on seeing this merged.

[akien-mga]

Thanks!

[mihe]

I stumbled upon a regression that seems to have been caused by this PR, where you're no longer able to use the list of selectable (overlapping) nodes feature in the 3D editor.

I put up a fix in #94387, in case anyone wants to take a look.

[mihe]

I'm also noticing that the code for this list selection feature now differs between 3D and 2D, where the 3D list selection now incorporates the logic from CanvasItemEditor::_find_canvas_items_in_rect that was mentioned above but the 2D list selection still just overwrites selection_results with the results from CanvasItemEditor::_get_canvas_items_at_pos, much like what the 3D editor did before.

Is that something that should be addressed?

EDIT: When taking a closer look at CanvasItemEditor::_get_canvas_items_at_pos, it seems to be doing some kind of filtering that's similar to what this PR introduces, so maybe it's fine?