[rcore] Fix native win32 window minimizing/maximizing

[mikeemm]

This PR aims to fix window minimizing/maximizing and overall resizing behavior in native win32 windows. While the first couple commits already enable mizing, there's still a variety of issues to track down:

• FLAG_WINDOW_RESIZABLE lets the window be resized by dragging the borders, but it won't enable the maximize button in the decorator.
• Even when said flag has not been activated, the window can still be maximized through code, and it can be resized to the default size by dragging the window when it is maximized (which then also pauses the app).
• Regarding pausing, FLAG_WINDOW_ALWAYS_RUN cannot be set and pausing is inconsistent, as the app may run while minimized and pause when restored depending on how the window has been manipulated.
• Maximizing after minimizing does not work as it is unable to update the flag.
• The app's icon does not appear until you minimize the app manually: minimizing through code instead before having first done so manually will require the user to delete it through the task manager instead.

[mikeemm]

I believe all the issues I mentioned are now fixed except for FLAG_WINDOW_ALWAYS_RUN, as it wasn't as simple to implement as I assumed and I believe it should be addressed separately. If there are any other related issues or scenarios I missed, please let me know.

I am a bit unsure about the last commit, where I extended SanitizeFlags() to handle illegal cases. I have a feeling that it might be seen as too much hand holding, though I believe that it is better to give users a warning and undo their mistake when they've clearly mixed up the wrong flags rather than essentially crash their application with a relatively cryptic error message; especially with one of raylib's focuses being as an educational tool. I also think that the bitwise conditionals get a bit hard to read, but replacing the duplicate flags with variables looks even uglier, and they're used so much throughout the code that replacing them with FLAG_IS_SET seems like something better left for a PR refactoring the whole file. Thoughts?

[raysan5]

@mikeemm thanks for the improvements, look good to me!

I am a bit unsure about the last commit, where I extended SanitizeFlags() to handle illegal cases. I have a feeling that it might be seen as too much hand holding

I agree, actually at this moment I think it's the only platform with that kind of sanity-checks on flags. It's ok for now but I think user should be responsible of their decisions if trying to set incompatible flags.

though I believe that it is better to give users a warning and undo their mistake when they've clearly mixed up the wrong flags rather than essentially crash their application with a relatively cryptic error message

Absolutely, actually raylib always use some that approach: a warning and some fallback mechanism.

I also think that the bitwise conditionals get a bit hard to read, but replacing the duplicate flags with variables looks even uglier, and they're used so much throughout the code that replacing them with FLAG_IS_SET seems like something better left for a PR refactoring the whole file. Thoughts?

I already replaced all bitwise operations by the provided macros on rcore_desktop_glfw and it should be replaced also on this backend for consistency:

// Flags bitwise operation macros
#define FLAG_SET(n, f) ((n) |= (f))
#define FLAG_CLEAR(n, f) ((n) &= ~(f))
#define FLAG_TOGGLE(n, f) ((n) ^= (f))
#define FLAG_IS_SET(n, f) (((n) & (f)) == (f))

I'm merging this PR for now.