Windows: Implement EventLoopExtPumpEvents and EventLoopExtRunOnDemand

A surprising amount of work was required to enable these extensions
on Windows.

I had originally assumed that pump_events was going to be very similar
to run except would use PeekMessageW instead of GetMessageW to avoid
blocking the external loop but I found the Windows backend broke
several assumptions I had.

Overall I think these changes can hopefully be considered a quite a
significant simplification (I think it's a net deletion of a fair amount
of code) and I think it also helps bring it into slightly closer alignment
with other backends too

Key changes:
- I have removed the `wait_thread` that was a fairly fiddly way of handling
  `ControlFlow::WaitUntil` timeouts in favor of using `SetTimer` which works
  with the same messages picked up by `GetMessage` and `PeekMessage`.
- I have removed the ordering guarantees between `MainEventsCleared`,
  `RedrawRequested` and `RedrawEventsCleared` events due to the complexity in
  maintaining this artificial ordering, which is already not supported
  consistently across backends anyway (in particular this ordering already
  isn't compatible with how MacOS / iOS work).
- `RedrawRequested` events are now directly dispatched via `WM_PAINT` messages
  - comparable to how `RedrawRequested` is dispatched via `drawRect` in the
  MacOS backend.
- I have re-worked how `NewEvents`, `MainEventsCleared`, and `RedrawEventsCleared`
  get dispatched to be more in line with the MacOS backend and also more in line
  with how we have recently discussed defining them for all platforms.

  `NewEvents` is conceptually delivered when the event loop "wakes up" and
  `MainEventsCleared` gets dispatched when the event loop is about to ask the
  OS to wait for new events.

  This is a more portable model, and is already how these events work in the
  MacOS backend.

  `RedrawEventsCleared` are just delivered after `MainEventsCleared` but this
  event no longer has a useful meaning.

Probably the most controversial thing here is that this "breaks" the ordering
rules for redraw event handling, but since my changes interacted with how the
order is maintained I was very reluctant to figure out how to continue
maintaining something that we have recently been discussing changing:

https://github.com/rust-windowing/winit/issues/2640.

Additionally, since the MacOS backend already doesn't strictly maintain this
order it's somewhat academic to see this as a breakage if Winit applications
can't really rely on it already.

This updates the documentation for `request_redraw()` to reflect that we
no longer guarantee that `RedrawRequested` events must be dispatched
after `MainEventsCleared`.

src/window.rs

@@ -524,25 +524,25 @@ impl Window {
         self.window.scale_factor()
     }
 
-    /// Emits a [`Event::RedrawRequested`] event in the associated event loop after all OS
-    /// events have been processed by the event loop.
+    /// Requests a future [`Event::RedrawRequested`] event to be emitted in a way that is
+    /// synchronized and / or throttled by the windowing system.
     ///
     /// This is the **strongly encouraged** method of redrawing windows, as it can integrate with
     /// OS-requested redraws (e.g. when a window gets resized).
     ///
-    /// This function can cause `RedrawRequested` events to be emitted after [`Event::MainEventsCleared`]
-    /// but before `Event::NewEvents` if called in the following circumstances:
-    /// * While processing `MainEventsCleared`.
-    /// * While processing a `RedrawRequested` event that was sent during `MainEventsCleared` or any
-    ///   directly subsequent `RedrawRequested` event.
+    /// Applications should always aim to redraw whenever they receive a `RedrawRequested` event.
+    ///
+    /// There are no strong guarantees about when exactly a `RedrawRequest` event will be emitted
+    /// with respect to other events, since the requirements can vary significantly between
+    /// windowing systems.
     ///
     /// ## Platform-specific
     ///
+    /// - **Windows** This API uses `RedrawWindow` to request a `WM_PAINT` message and `RedrawRequested`
+    ///   is emitted in sync with any `WM_PAINT` messages
     /// - **iOS:** Can only be called on the main thread.
-    /// - **Android:** Subsequent calls after `MainEventsCleared` are not handled.
     ///
     /// [`Event::RedrawRequested`]: crate::event::Event::RedrawRequested
-    /// [`Event::MainEventsCleared`]: crate::event::Event::MainEventsCleared
     #[inline]
     pub fn request_redraw(&self) {
         self.window.request_redraw()