As we have done in #2331 by emitting Resumed on every platform somewhere after the loop starts (for platforms that don't have an explicit point/callback where this should happen) to consistently implement surface creation, we should likely do the same with Suspended on loop shutdown for platforms that don't have an explicit callback here. This will allow implementers to perform surface destruction in a single consistent place too.

I'm currently improving a random winit sample to utilize these events, and the implementation becomes clumsy when having surface destruction in both LoopExiting and Suspended. It might even conflict with WindowEvent::Destroyed.

On Android I'm not yet sure if triggering a loop exit would terminate the Android app in such a way that surface destruction (== Suspended) is raised prior to LoopExiting anyway.

Side-note: Android supports multiple windows, and once the backend crates handle that properly perhaps Resumed needs to be moved to a WindowEvent, and Suspended will become Destroyed?