Fixes #110643.

This is a workaround to a very annoying problem, and I'm really not sure how to explain it in simple terms¹.

On Godot, each window's size is exactly that of the underlying buffer (let's call it an "absolute size").

On Wayland and MacOS, windows have a dpi-independent "logical size". If the system scale factor isn't 1, the underlying buffer grows/shrinks to accommodate that.

This difference causes some very annoying issues which currently require workarounds².

The biggest issue here is that, since the engine uses absolute units, there's no way to tell the reason behind the resize. This means that whenever the buffer changes size to account for scaling, that is effectively treated as the actual window size (as if the user resized it themselves) and stored e.g. in the Window node.

Whenever a Window node hide()s and show()s, the size will be adjusted and fed back, meaning that the effective window will grow more and more.

While it may be possible to make the Wayland backend "buffer-centric" it's discouraged to as the API is really not built for that and it would cause bad user UX. Additionally, after some discussion it looks like there's no way around it, with "logical size" being a concept we need for good engine-wide per-viewport dynamic DPI scaling anyways, so I'm proposing the following workaround in the meantime:

• Add a new (unbound) method in DS: window_get_scale. By default, it returns the window's screen scale, but on Wayland it returns the actual per-window scale.

• Only on platforms with FEATURE_SELF_ADJUSTING_WINDOWS³, in window.cpp, we "unscale" the window rect whenever the window is unmapped.

• [Editor specific] Additionally, on platforms with the above flag, we also use the default position and screen whenever it is restored from memory. That system is already, as is, very limited on Wayland anyways, being limited to storing the size. Perhaps a more proper fix would be to do the adjusting every time the window size is saved, but I tried to be as little invasive as possible.