Fix the behavior of the resource property of the sub-scene root node on instantiation

[Rindbee]

See #64999 (comment), this PR complements it.

The sub-scene root node will be set successively in the sub-scene and the main scene.

In the following tables, the R prefix indicates a resource that does not have resource_local_to_scene enabled. The RL prefix indicates a resource with resource_local_to_scene enabled.

A gray background means that the record will be empty; others will still create a new record in the main scene.

In the case marked in yellow above, it is actually impossible to determine whether a new RL1 or an old RL0 is used.

The PR is simply to determine intent from the record, the above yellow cases are considered RL0. Mainly the cases when resource_local_to_scene is enabled in main scene.

After setting the properties of the sub-scene root node, call setup_local_to_scene() on the nested resource with resource_local_to_scene enabled so that the nested resource is setup correctly.

When updating resources according to the records of the main scene, use the scene_unique_id in the main scene to prevent the ID of the resource from changing continuously when saving the scene.

Fix #77997, fix #76693.

[RandomShaper]

I can't really test all the new changes. They look overall good.

[RandomShaper]

I was wondering if we could remove part of the recently added logic to scene instantiation (including the present PT) and do the fix instead at scene packing time; i.e., store nodes that wouldn't normally be stored for being pure instances in case they have properties pointing to local-to-scene resources, and store only those properties. @Rindbee, thoughts?

Aside again, I've tagged this PR for cherry-picking into 3.5 and 3.x, like the previous ones regarding this. However, given the changes are starting to get a bit complex and error prone, I'm wondering if they shouldn't be cherry-picked into 3.5 for the time being, to avoid regressions. @akien-mga, thoughts?

[akien-mga]

Yes any change to PackedScene will cause regressions in my experience :) This series of changes should not be cherry-picked for 3.5.

Stable branches should only get safe fixes (or if unsafe, they need to be critical fixes worth the risk of regression).

[Rindbee]

I think it's worth a shot, some things are easier to handle when packing.

[RandomShaper]

I'll untag from 3.5 all the PRs in the changeset.

[RandomShaper]

All the related (merged and not yet merged) PRs are now only tagged for being cherry-picked into 3.x.
That said, @Rindbee, bear in mind that some changes may not be trivially cherry-pickable. Such cases would require dedicated PRs for 3.x.

[RandomShaper]

I think it's worth a shot, some things are easier to handle when packing.

So, do you still want to have this one merged or you'd rather try the other way first?

[Rindbee]

I'm now more familiar with scene instancing than scene packaging, so learning scene packaging may take more time.

There is no need to merge it now, and it may be revised later.

[RandomShaper]

Will you split this PR into two? The part affecting instantiation and the part affecting node copy? The latter is ready to be merged right away. The former could be kept in standby until you decide.

[Rindbee]

The previous copy_from is directly replaced with the attribute value in the source resource, which is similar to the previous situation of the sub-scene root.

When local-to-scene is enabled, it is desirable to keep the previous resource instance, because direct replacement will break the sharing relationship.

These situations may currently exist:

1. node->res1(local)
2. node->res2(local)->res1(local)
3. node->res3->res1(local)

Although the cases of 2 and 3 may be rare.

Now hopefully 1 and 2 are properly resolved. As for 3, it's a bit difficult. Edit: I think its more like a bug, res3 is shared globally.

[Rindbee]

OK, what can be done has been done.

3. node->res3->res1(local)

I think it's better to treat it as an error when instantiating, res3 that can be shared globally should not have local-to-scene sub-resources.

A possible solution is to propagate the local-to-scene of res1 to res3, i.e. res3 is also local-to-scene. It may be more appropriate to deal with it when packing.

[RandomShaper]

Well, if this already fixes some cases I think the best thing at this point is to have it merged. That will make it easier to track this waterfall of changes about instantiation and local-to-scene resources. If you at some point find a good way to do some of the fixes at packing time, I gues there's no harm in a new PR that partially reverts the current approach and adds the new way.

[akien-mga]

Thanks!