[3.x] Add content scale stretch modes, implement integer scaling

[Riteo]

Supersedes (and based on) #63206
Improves godotengine/godot-demo-projects#898
3.x version of #75784

Implements a new display/window/stretch/stretch project setting and the ScaleStretch enum, controlling the way the game scales the content while stretching it.

This is different from the stretch mode as this defines what rules to apply when deciding how much to stretch, instead of governing how.

Integer scaling is achieved (after aspect expansion) by "lying" to the stretching code about the window's size, telling it that it's always an integer multiple of the viewport so that it only gets stretched to an integer factor.

This approach works with all stretch and aspect modes and doesn't require handling for each, only requiring to "loosen up" some self-excluding conditions (in other words, replacing some else ifs with just ifs) regarding viewport offset and margin calculation (black bars).

Notes:

• Perhaps even worse than Add content scale stretch modes, implement integer scaling #75784, I really don't like the name and it clashes even more with 3.x naming. I'm not sure on how to name it. Perhaps I could name the enum StretchScale? Again, no idea.

• 3.x has this huge method (set_screen_stretch) which sets up everything else regarding screen stretching. I implemented another method (set_scale_stretch) to not break API compatibility.

• This has only been lightly tested on my NVIDIA/X11 desktop, as I mostly use 4.x and Wayland on my laptop, which is only supported there. That said, the code is almost identical to its 4.x counterpart and the porting job was trivial, having just to compensate for a bunch of 3.x-isms. I'm thus pretty sure that this should work as well as Add content scale stretch modes, implement integer scaling #75784.

[Riteo]

Ugh, 3.x doesn't have a content scale factor but a "shrink" property. I'll have to port it properly. Marking as draft.

[Calinou]

Ugh, 3.x doesn't have a content scale factor but a "shrink" property. I'll have to port it properly. Marking as draft.

The goal was originally to have a content scale factor in 3.4, but we decided to merge both into the existing shrink property for backwards compatibility. (Content scale factor is essentially 1.0 / shrink.)

[Riteo]

@Calinou I see, so it shouldn't take much to port the scale flooring to it.

Thinking about it, would it be a good idea to touch that value at all? If the user sets a shrink/CSF of 0.6, they would probably expect a non even-result in the first place, but that would be still stretched by an integer factor.