`MonitorHandle` and `VideoMode` can become invalid leading to panics

This is an issue in MonitorHandle and VideoMode. In https://github.com/rust-windowing/winit/pull/3303#discussion_r1436573528 @madsmtm has pointed out that on MacOS these handles are not connected to EventLoop in any way, so they should be fine. We should try and cover all backends and make sure handle method can't and can live after the event loop is exited or otherwise come up with an alternative, e.g. adding a lifetime.

• Rename VideoMode to VideoModeHandle, similar to other types, to represent that they don't just hold static data: #3328.
• Rename it back into VideoMode, but make it hold only data: https://github.com/rust-windowing/winit/pull/4060.
• Both MonitorHandle and VideoMode can become invalid, e.g. a monitor gets disconnected. So all methods should return an error to handle that.
• AFAIK on Linux these types are connected to the EventLoop so we have to come up with a good solution. This is a similar problem to #3317.

Cc #971, https://github.com/rust-windowing/winit/issues/3102 and #2646.

Original Windows only issue

The MonitorHandle on Windows holds a HMONITOR, which can become invalid if e.g. the monitor is disconnected. Or to be more precise, the Windows documentation recommends to listen to WM_DISPLAYCHANGE, which can potentially invalidate any HMONITOR.

All of the MonitorHandle methods call the GetMonitorInfo function and just unwrap(), which would cause a panic if a HMONITOR has become invalid.

See #3255, which only fixed MonitorHandle::video_modes().

Trace the MonitorHandle and VideoMode implementations across the platform backends, starting with the methods that call GetMonitorInfo and the EventLoop relationships described here. Compare backend behavior when monitors disconnect or the event loop exits, then define coverage that ensures invalid handles are handled without panics and methods report errors consistently.