Retain configuration meta data on ProjectSettings

[BastiaanOlij]

This is a brute force fix for #25661 (and similar bug reports). It's probably good enough but it's worth having a discussion whether we want to make much more work out of this.

The core problem here is that when we select a project from the list and do something with it, we instantiate a new instance of ProjectSettings. At this point in time that projects settings takes over as the singleton in memory and we loose access to the original singleton created at startup that contains our full set of registered settings especially now that we only save settings that the user has changed from default.

This results in two sets of behaviors:

1. when we popup dialogs we check for settings but we're now taking settings from the last loaded project files, not the settings for our object for our project manager
2. we get a lot of error spam as when we access settings that aren't present because they were left on default and never saved

(and then a 3rd potential issue is that we could destroy our new ProjectSettings object and have our singleton pointer becomes a nullptr)

A brute way to solve this is to check if we already have a singleton in our constructor, make a copy of our properties and set everything to default, this is what I'm doing here but it only solves issue number 2 and not in a consistent way.

The nice way to solve it would be that only our object constructed in main becomes our singleton, and the additional objects don't, but our whole API for accessing settings is based around our singleton access. This would be a major undertaking to ensure that our macros are only used for accessing the settings loaded at startup, and any access to settings within the class itself and when the project manager access settings for other projects, we do not rely on the singleton logic.

We could still merge this as an interim solution as it makes nothing worse than it already is, and look at doing the work to make it nicer some time in the future.

[akien-mga]

I think this is the wrong approach. If I understand the issue correctly, it happens only in the Project Manager's "Rename" dialog, due to very hacky code handling MODE_RENAME:

editor/project_manager.cpp
439:                    ProjectSettings *current = memnew(ProjectSettings);
697:                    ProjectSettings *current = memnew(ProjectSettings);

There's no reason to instantiate a new ProjectSettings here.

We should fix the Project Manager so that it doesn't do that (and ProjectSettings's constructor should have an ERR_FAIL_COND(singleton != nullptr); to prevent such hacky code in the future).

[YuriSizov]

You could probably use ConfigFile for the rename functionality.

[akien-mga]

Superseded by #69338.

[BastiaanOlij]

Thanks @akien-mga , indeed I wasn't sure about the fix so good to see we have something better :)