Make 0.4 -> 0.5 not a breaking change by adding deprecated items

[madsmtm]

Solves rust-windowing/winit#2415.

After this, we can then release v0.4.4 as just a re-export of v0.5.1.

Of course we will have to remove these at some point, but at least it can wait until the next major release, at which point we may be ready to declare a v1.0 and won't have to deal with breaking changes any more.

CC @rib @maroider @kchibisov

[rib]

Just to be clear here though; to support backwards compatibility I think this approach also requires Winit to fill in those deprecated window-handle struct members right?

As in doesn't provide transparent compatibility between Winit based on raw_window_handle 0.5 (which only puts the display state in the display handles currently) and something like Wgpu 0.13 that wants window-handles that contain display state.

[madsmtm]

Just to be clear here though; to support backwards compatibility I think this approach also requires Winit to fill in those deprecated window-handle struct members right?

As in doesn't provide transparent compatibility between Winit based on raw_window_handle 0.5 (which only puts the display state in the display handles currently) and something like Wgpu 0.13 that wants window-handles that contain display state.

Yeah, that would be required, though winit would be able to drop support for it e.g. in v0.28.0, when it is expected that wgpu and such have updated to raw-window-handle v0.5

[maroider]

I think it makes the most sense to move forward with rust-windowing/winit#2418 at this point.

[kchibisov]

Closing in favor of winit patches.