Restore bounds for Quick Open and all dialogs that inherit AcceptDialog

[actforjason]

This PR adds persistence for dialog bounds (position and size) for the Quick Open, Scene Tree dialogs etc. similar to how it is handled in the Create Dialog, as a lightweight alternative for #106648
Close godotengine/godot-proposals#5005

The previous PR introduced a session_id to make dialog bounds restoration work in-game. However, that approach still has some unresolved issues and maybe requires further adjustments to integrate.

This PR proposes a less intrusive solution that aligns with the current implementation of Create Dialog, allowing this feature to be completed sooner. A more comprehensive refactor, either of the existing approach or at the project level, can be considered in the future.

[actforjason]

@ArchercatNEO I implement storage and restoration of window bounds in the base class AcceptDialog of all dialogs to avoid setting them one by one. Do you think this method is ideal?

[ArchercatNEO]

@ArchercatNEO I implement storage and restoration of window bounds in the base class AcceptDialog of all dialogs to avoid setting them one by one. Do you think this method is ideal?

I implemented session_id based on instances of windows instead of classes of windows for a reason: I see that you’re using class_name as a key (which is good, it means each class has a different key) but if we ever try to make two different dialogs that both use the same class, they would share their window bounds. I believe this is a restriction that could lead to strange behaviour (like a window being restored where an unrelated window was last closed) but if you believe this is not a concern I would say this is a reasonable implementation.

Another reason I wanted to implement session_id is that on Wayland since windows cannot position themselves we cannot restore windows with this method. There exists a protocol (xdg-session-management) which allows the compositor to restore windows if they are assigned an id (with the same restrictions as my own implementation of session_id) but since this is a lightweight PR and conforms to current implementations I don’t to want to hold this against this PR.

However, there is a problem with using EditorSettings in scene. We’re not allowed to make scene depend on editor (not even behind #ifdef TOOLS) . This is the reason I re-created my own version of them in DisplayServer. I don’t believe EditorSettings are fundamental to the approach here, you need to find somewhere else to put the file management.

[actforjason]

I see that you’re using class_name as a key (which is good, it means each class has a different key) but if we ever try to make two different dialogs that both use the same class, they would share their window bounds. I believe this is a restriction that could lead to strange behaviour (like a window being restored where an unrelated window was last closed) but if you believe this is not a concern I would say this is a reasonable implementation.

In the editor environment, it is reasonable for dialogs of the same class to share bounds to avoid repeated adjustments, and it seems that multiple dialogs of the same class will not appear at the same time (useless?).

As for EditorSettings, I decided to use it this way after seeing that several scripts in scene have introduced editor/... through #ifdef TOOLS_ENABLED. I don’t know the maintainer’s opinion yet. Otherwise PR will be too broad.