Windows not sending WindowEvent::RedrawRequested when request_redraw is called

Description

This is most likely related to #3648
As far as I can tell RedrawRequest is only sent here
https://github.com/rust-windowing/winit/blob/93045a5b512edbd1e95eb8d8b396e1bdfeafed93/winit-win32/src/event_loop.rs#L1304-L1313

Digging into windows documentation WM_PAINT is only sent by the system or when another application makes a request to paint a portion of an application's window (https://learn.microsoft.com/en-us/windows/win32/gdi/wm-paint) and that it will only be sent when there are no messages in the application's message queue.

So when you are for example actively moving the mouse in the window and you are requesting a redraw after each event and this redraw is not quick enough, RedrawRequest will not be sent as next event like on other platforms and will wait until you either slow down or stop as the message queue fills up in between. This could be seen in: https://github.com/DioxusLabs/blitz/issues/595 where redrawing at 300+ fps isn't fast enough for the message queue to stay empty for WM_PAINT to happen.

#4653 that apparently fixes #3648 does not fix this issue

Windows version

Microsoft Windows [Version 10.0.26200.8875]

Winit version

0.31.0-beta.2

Start by reading winit-win32/src/event_loop.rs around lines 1304-1313, then compare the WM_PAINT behavior described in the issue with request_redraw during sustained mouse movement. Reproduce the reported case on Windows 10 with winit 0.31.0-beta.2; done means WindowEvent::RedrawRequested is delivered without waiting for the message queue to become idle.