Various bugs related to Window sizes

I was testing the window API to be able to document it: https://github.com/bevyengine/bevy/pull/8858

I encountered several behaviours that look like bugs. I considered they are bugs in https://github.com/bevyengine/bevy/pull/8858 so if they're not then the doc needs to be changed again!

I will update this PR if some of those are fixed, I will keep the "numbers" so you can refer to a specific one.

For information I tested on main (pre 0.11.0) on Linux Mint with X11, with a single monitor and a `base_scale_factor` of `1.`.

### 1) `set_scale_factor_override` doesn't restrict physical size after fullscreen is reached (?)

For this one the `scale_factor_override` example can be used, just add `dbg!` macros to track the `height/width/physical_height/physical_width` in the `display_override` system.

When you press up, the logical size doesn't change at first, only the physical size does, which is intended.
When you press a few more times, at some point the window will fill the screen, and the logical size will change, and the physical_size will be set roughly to the size of the screen, also intended.
When you press even more, I would expect the logical size to keep changing (reducing) and the physical size to stay the same, but instead the logical size doesn't change and the physical size continues growing.

This is not a problem with desynchronisation, the window effectively grows larger than the screen (on my linux, the title is in the middle of the top bar, it will go right because the window is extending outside of the screen, and also I can move the window around and see it's bigger).

### 2) `WindowResizeConstraints` logic ignores `scale_factor_override`

The documentation of `WindowResizeConstraints` states "These values are measured in **logical pixels**, so the user's scale factor does affect the size limits on the window." but it is not true: at creation, when resizing with code (`WindowResolution::set`) or when resizing by hand (with your mouse), the limits are actually **physical pixels**.

I kept that sentence in https://github.com/bevyengine/bevy/pull/8858 because I think that should be the behaviour, but the documentation is incorrect.

Edit: upon code inspection, `WindowResizeConstraints` seem to actually indicate logical size (my `base_scale_factor` was `1.`), but actually ignores `scale_factor_override`. Changed title from "`WindowResizeConstraints` uses physical size" to "`WindowResizeConstraints` logic ignores `scale_factor_override`"

### 3) Resizing with code while in Fullscreen mode

Using `WindowMode::BorderlessFullscreen`, `Fullscreen` or `SizedFullscreen` (didn't test that last one), then (after the fullscreen is applied) resizing with code (`WindowResolution::set`) to a lower size, the window takes only part of the screen, and the rest of the screen is just "not updated" (it displays the last thing displayed, like an afterimage).

I didn't test resizing to a bigger size, my guess is that it would have a weird behaviour too.

I think changing the size with `WindowResolution::set` when in fullscreen mode should either be ignored, with or without a warning, or `WindowResolution::set` should return a Result and return an error in that case.

### 4) Fullscreen mode with a `WindowResizeConstraints`

Creating a window with `WindowMode::BorderlessFullscreen` or `Fullscreen`, and with a WindowResizeConstraints with lower upper bounds than the size of the screen, will make the window take only part of the screen.

I think `WindowResizeConstraints` could be ignored in that case?

I didn't play with lower bounds and `SizedFullScreen` (I think WindowResizeConstraints make more sense with `SizedFullscreen` actually, it could also with `Fullscreen` and instead of taking the biggest size allowed by the screen we could change the resolution of the screen like `SizedFullscreen` does but take the biggest one within the constraints).

### 5) Resizing with code seems to ignore `WindowResizeConstraints`

`WindowResizeConstraints` seems to be taken into account only when creating the window, using `WindowResolution::set` seem to ignore it.

### 6) Panic when resizing to high values

Resize with code to high values, like `window.set(120000., 120000.)` triggers a panic.

### 7) Creating a window with a size outside of its constraints creates it within without a warning

See: https://github.com/bevyengine/bevy/issues/8921#issuecomment-1602204161

### 8) Resizing with code while in windowed mode and reaching fullscreen will desynchronize the values between Window and winit.

When setting the window size to larger and larger value until it fills the screen, the real window size is effectively contained within the screen, but the values inside the Window component will keep growing, because `WindowEvent::Resized` is not triggered in that case. When resizing the window manually (with the mouse) it "snaps" back to correct values.

### 9) Resizing with a very high WindowResizeContraint will break the resizing
See @RaphaelEDiener's comment https://github.com/bevyengine/bevy/issues/8921#issuecomment-1950241336

Reproduce the numbered cases with the `scale_factor_override` example and its `display_override` system, using `WindowResolution::set`, `WindowMode`, and `WindowResizeConstraints`. Then inspect the `Window` component and `WindowEvent::Resized` handling around the winit integration. Done requires agreeing on expected fullscreen, constraint, scaling, and oversized-window behavior, then covering the selected cases with tests.

Written by the indexing model from the issue text.