[rcore_desktop] Fix 3693 initial window geometry

[dertseha]

This pull request fixes #3693 .

Tested under MS Win11, with core_basic_window.c sample under raylib\projects\scripts\, using a three-monitor setup (see linked issue for monitor layout).

This pull request causes the following regarding window initialization, when started via file-explorer without console on the three screens:

• windowed (InitWindow(>0, >0, ...)): window is of requested size, always centred on the monitor where file-explorer is
• fullscreen (SetConfigFlags(FLAG_FULLSCREEN_MODE);): Always a fullscreen window on the primary monitor
• windowed fullscreen (InitWindow(0, 0, ...)): window is of monitor size, filling the monitor where file-explorer is *)

Approach

• Fullscreen applications use the primary monitor, exclusively. This is as per recommendation of comment from glfwCreateWindow(), which states "Unless you have a way for the user to choose a specific monitor, it is recommended that you pick the primary monitor."
• Non-fullscreen applications will have their windows created in two flavours:
  • a) User specified an explicit dimension
  • b) User requested implicit monitor size by specifying width=0, height=0 (which mimics the behaviour of fullscreen apps)

Either way, non-fullscreen applications will be centred on the monitor where they are created.

The way this solution does this is by querying the monitor after creating the window, and then derive necessary sizes. This also needed a special case of implicit-monitor-sized windows to be created with an initial size of 1x1 pixels, as GLFW prohibits using 0x0.

Further changes (fixes)

The change of #3923 broke window positioning of a windowed fullscreen app on the primary monitor (on MS Windows): It ended up positioning the window at a very high Y coordinate. This is because the line

int posY = monitorY + (monitorHeight - CORE.Window.screen.height)/2;

has an integer overflow in case monitorHeight is less than CORE.Window.screen.height - since the second is an unsigned integer, the first one is treated as such as well, leading to an underflow to a very high unsigned integer value. Halving this then brings it back into possible ranges of a positive signed integer, which is then taken.

How is this possible? The intent is to avoid the taskbar, so monitorHeight is describing only the workable area, which is thus less than the screen height.

Side-note: This integer conversion issue is even highlighted in my IDE. There are several such notices across the codebase.

*) Unknown detail

On my MS Windows machine, creating a windowed fullscreen application on the primary monitor creates a window that has the size of the monitor, yet still shows the taskbar. So, the game considers a larger area to work in, but not all is visible, hidden behind the taskbar.
This is even the case before my change (and after the fix regarding positioning).
Is this the intention? This may require an additional fix.

[raysan5]

@dertseha Thank you very much for all the work put on this issue, I'll review it as soon as possible.

[raysan5]

@dertseha Merged! Thank you very much for reviewing this issue! This is a great improvement! Thanks!