win32: fix multi-window redraw starvation

[Niketion]

• Tested on all platforms changed (Windows)
• Added an entry to the changelog module if knowledge of this change could be valuable to users
• Updated the internal dispatch documentation
• Created or updated an example program if it would help users understand this functionality

Fixes #3648.

Multi-window redraw starvation

Dispatching a RedrawRequested interrupts Win32 message processing so that pump_app_events can promptly return control to its external event loop.

Previously, the next iteration could enter the wait phase and emit another AboutToWait before dispatching the remaining queued window messages. Applications requesting redraws again from AboutToWait could therefore repeatedly service one window while starving the others.

This change preserves the interrupted-dispatch state across pump_app_events calls and resumes pending message dispatch before entering another wait phase. run_app_on_demand likewise checks the interrupted state before preparing to wait. This restores fairness between windows while preserving pump_app_events behavior of returning after one RedrawRequested.

Testing

Tested on Windows across:

• ControlFlow::Wait and ControlFlow::Poll;
• run_app, run_app_on_demand, and pump_app_events;
• multiple windows and different redraw request orders;
• redraw requests made from inside RedrawRequested;
• cross-thread requests, window state changes, closure, and exit handling.

With equal request counts, the original five-window reproducer produced:

events=[0, 0, 0, 0, 500]

With this change:

events=[500, 500, 500, 500, 500]

[nicoburns]

I believe this PR currently has a problem where it will schedule a redraw for every single input event if the handler every event requests redraw, with no coalescing at all. I think we need some kind of middle ground where input events are processed in a batch up until some deadline or similar.

[Niketion]

Thanks, this is a valid concern. Addressing this correctly would require a more deliberate batching or deadline policy, together with broader testing across run_app, pump_app_events, multiple windows, and native modal loops. I think that goes beyond the original scope of this PR.

I’m going to revert the continuous-input/posted-message changes for now and keep this PR focused on the original multi-window starvation issue in #3648