Add DUPLICATE_NODE_REFERENCES flag to duplicate Nodes and change references to the newly duplicate Nodes

[Mickeon]

Closes #78060.

This PR adds a new flag to be used in Node.duplicate() called DUPLICATE_NODE_REFERENCES .
When added to the method, the newly duplicated Node and its children will "correct themselves". All exported Node properties will point to their respective nodes in the hierarchy, instead of the nodes of the original instance.

Alternatively. quoting the newly added description for it:

Duplicate the node's references, changing all exported Node properties to be part of the newly duplicated hierarchy, if possible. Does not work without DUPLICATE_USE_INSTANTIATION.

I apologise for the sheer amount of amends this PR has suffered from.

---

Stuff is still up the air. Perhaps this shouldn't even be a new flag, and just the default behavior of DUPLICATE_USE_INSTANTIATION? It can remain to be discussed.

Sidenote, the DUPLICATE_USE_INSTANTIATION description is completely screwed up and entirely incorrect. See #68560.

[RandomShaper]

The idea of it being the default behavior of DUPLICATE_USE_INSTANTIATION is intriguing. I worked on this baaack in time, but I think the rationale still stands: duplicating a node, without that flag, means raw duplication, which is what you may want in some cases; however, if your node is a scene/prefab, something you encapsulated to intantiate as a self-contained thing, and you make that explicit by using DUPLICATE_USE_INSTANTIATION, to me, the internal node paths should be fixed up to point within the instantiated scene. So, that not being the case looks like a bug to me indeed.

[RandomShaper]

Aside, I wonder why DUPLICATE_USE_INSTANTIATION is a must. In other words, iIf we kept DUPLICATE_NODE_REFERENCES for raw duplicate, why wouldn't it work?

[Mickeon]

to me, the internal node paths should be fixed up to point within the instantiated scene. So, that not being the case looks like a bug to me indeed.

I agree wholeheartedly. I would fix it, myself.
Another problem arises, however. Doing so would technically break compatibility.
I personally think it would be worth it. The users from the issue above literally cannot use duplicate normally because it doesn't work the way one may expect, but I'm just one man.

Aside, I wonder why DUPLICATE_USE_INSTANTIATION is a must. In other words, iIf we kept DUPLICATE_NODE_REFERENCES for raw duplicate, why wouldn't it work?

I was waiting to personally test it. I... actually do not know. This actually works without it, I just realised. It's just that it's almost functionally useless without the DUPLICATE_USE_INSTANTIATION or DUPLICATE_SCRIPTS flags, because any scripts the developer may have set are not carried over in any way.

[Mickeon]

I want to also note. This was not a possible situation in 3.x because exporting Node properties was not possible (only NodePaths).
This is a new feature of 4.x. @onready Nodes are not affected by this, exported NodePaths are not affected by this. So this may actually be considered unexpected behavior to be fixed, indeed.

[RandomShaper]

I personally think it would be worth it. The users from the issue above literally cannot use duplicate normally because it doesn't work the way one may expect, but I'm just one man.

I think the revised behavior would be clearly the right one. An explanation in the release notes should be enough.