Fix saving .tres file with Dictionary/Array containing Resources does not work

[Maran23]

NOTE: Probably superseded by #62318

Fixes #55885

After some discussion (see comments) and thinking I came to this solution.
The check, if a resource should be saved by checking whether it or its sub-resources have been edited now takes arrays and dictionaries into account.

I also tried changing the logic in the saving done by the ResourceFormatSaverTextInstance(resource_format_text.cpp), but found some problems/insecurities doing so:

1. The logic in there is a bit different for PROPERTY_USAGE_RESOURCE_NOT_PERSISTENT
   and res->get_path().is_resource_file().
2. I'm not sure if editor_node.cpp is only calling the save method of ResourceFormatSaverText. If not, then other subclasses of the ResourceFormatSaver needs to be adjusted as well (e.g. ResourceFormatSaverBinaryInstance, logic in here looks very similar).
3. If a subresource was edited, we still need to save the whole main resource, otherwise data will be lost.

Example: A.tres

Array (first)
- [0] Array (second)
---- [0] String (edited)
- [1] String

Now if we were to save only the edited part, we would save the second array because the string in it was edited, and lose the first array and the file will be corrupt as a result.

So if we want to remove the logic in editor_node.cpp and let the resource_format_text.cpp do the whole job, it needs to be refactored to save the whole resource when at least one subresource was edited (and of course the other two points need to be clarified).

[reduz]

I will give it a check soon. From what I remember this checked whether resources that were part of sub-resources forced the main one to be saved.

[Maran23]

I will give it a check soon. From what I remember this checked whether resources that were part of sub-resources forced the main one to be saved.

Nearly right. With my PR the code is more aligned to the actual saving algorithm. While the saving algorithm will also save all sub resources, so e.g. an Array in a .tres file. But the before called _find_edited_resources does not check whether sub resouces are edited and therefore should be saved later on.
Actually, my code can be further improved to also check nested resources of a nested resource and so on. Currently is does only check the first sub resource without going deeper, e.g. Array in Array won't be found with this.
That is probably more work given the current structure.

[reduz]

Okay sorry it took so long, I understand this bug well now as this is very old code. I am not entirely sure at this point whether we should even keep this code and instead now iterate through all loaded resources, check that they were edited and simply save them. I will discuss this a bit with other contributors and get back.

[Maran23]

Okay sorry it took so long, I understand this bug well now as this is very old code. I am not entirely sure at this point whether we should even keep this code and instead now iterate through all loaded resources, check that they were edited and simply save them. I will discuss this a bit with other contributors and get back.

No problem. I had the same thought. It is probably better to do that when saving. This will simplify the code since only location does the check and saving now - and it will probably also increase the performance a bit.

[Maran23]

I updated this PR and it is now ready for review. I have written my results and findings in the description.
The solution now fixes the problem and will also work for nested arrays/dictionaries (unlike my previous approach).
So if we edit a value inside an array in an array in an array... the resource will be recognized and saved now.

[Maran23]

Btw. the CI error does not look like something caused by my changes (status code 503). Can someone retrigger the JavaScript Build? I think I can't.

[kleonc]

Btw. the CI error does not look like something caused by my changes (status code 503). Can someone retrigger the JavaScript Build? I think I can't.

Done (and it indeed succeeded now).

[reduz]

I attempted an even simpler version of this in #62318 which should solve this problem too.

[akien-mga]

Superseded by #62318. Thanks for the contribution nevertheless!