"Making Unique" resource collections in derived scenes replaces resource elements in base scenes.

[willnationsdev]

Godot version:
Godot 3.1 stable mono

OS/device including version:
Windows 10

Issue description:
If you have a resource container and a resource element inside of that container, and if both of these resources are embedded resources inside of a scene file, then attempting to "Make Unique" the resource container in a derived scene will correctly create a deep duplicate of the resource container (that is, the derived scene will now have its own copies of the sub-resources, i.e. the resource container and the resource element).

However, if you look back at the base scene, you will see that the base resource element, which previously had a path residing in the base scene, will now be replaced with a resource path referring to the newly created embedded resource element in the derived scene.

This should not happen. It should instead retain its original copy of the resource element, that way the base scene and derived scene, upon making the resource container unique, will each have their own containers with each their own copies of the resource elements.

Steps to reproduce:
The demo below uses a resource collection from godot-next called a ResourceSet that is a thin layer around a Dictionary of Script -> Resource pairs. It makes a GUI that guarantees only one Resource of any kind will exist and allows you to constrain the collection's elements to a particular scripted type.

In the demo, the constraint type is "Behavior", another resource in godot-next. Its features are not relevant to this Issue. The demo introduces a "Bad" resource which derives Behavior and contains an integer "Num" exported property.

The ResourceSet is present on a CallbackDelegator node (another godot-next type) which serves as the root node of the res://scenes/other.tscn scene. There is also a derived res://scenes/other1.tscn scene.

If one opens the other1.tscn scene and expands all of the resource paths in the Inspector, they will see other.tscn:1 for the ResourceSet and other.tscn:2 for the Bad instance within it (if you don't see one, click the '+' icon to add it).

Then, if you click the "Make Unique" tool in the other1 scene's ResourceSet instance and save the scene, the resource paths will update to where the ResourceSet is now other1.tscn:2 and the Bad instance inside of it is other1.tscn:1. So, the ID numbers have swapped, and both are now stored inside the other1 scene. The ID numbers swapping is irrelevant, but the "other.tscn" becoming "other1.tscn" is correct behavior.

If you then move over to res://scenes/other.tscn and examine the same resource paths in the Inspector, you will notice that the ResourceSet is still pointing to other.tscn:2, but the Bad instance has now changed to be other1.tscn:1. This is the problem as it should have kept itself as other.tscn:1 so that the embedded, embedded resource is still referring to the original scene.

Minimal reproduction project:
nested_resources_test.zip

[willnationsdev]

Now that I think about it, this is probably happening because even though the resource collection is being made unique, the resource element is not getting a deep copy of itself made since it hasn't been made unique explicitly yet. However, if that were the case, and only a shallow copy of the resource element is passed along to the derived scene, then I would have expected other1.tscn's resource element to be referring to other.tscn's element rather than the other way around. The base scene shouldn't start looking at the derived scene's embedded instance. It should continue to maintain its own while the derived scene starts looking at the base scene's embedded instance. Though, ideally there would also be the option of recursively creating deep copies of all internal resources.