Make winit completely platform-agnostic

[madsmtm]

Builds upon: #2421.
Related: #2093

A great thing about winit is how it supports a varied number of different platforms. I would like to make it even easier to add support for new platforms. Possible examples include: Mac Catalyst, GNUStep, X11 on macOS, SwiftUI, GTK, KMS/DRM, WinRT, and whatever new thing that vendors may decide we should start using.

We already have code in src/platform_impl/linux/mod.rs to handle the fact that both X11 and Wayland can be present on the same target. While some of the above examples can be bolted on to that existing system, I really feel we need a generic way to handle the cases where more than one platform may be available on a specific target. This PR is an attempt at that.

The basic idea is to take the x11_or_wayland! macro, extend it a bit, and then handle delegation to the desired platform at the top level instead (e.g. inside src/event_loop.rs, src/window.rs, ...).

I haven't implemented this everywhere yet, wanted to get some feedback first, but compare src/platform_impl/linux/mod.rs and src/event_loop.rs in commit e74b801 to get a feel for what this would look like.

In the end, we would end up with the following directory structure:

src/platform_impl/
    android/
    ios/
    macos/
    unix/utils.rs // Shared utility functions between Unix platforms, if needed
    wayland/
    web/
    windows/
    x11/
    mod.rs

(This would also make Wayland and X11 feel a lot less like second-class citizens).

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation

[rockisch]

While looking for WinRT support, I one way or another ended up in this PR, and although I understand there are no current plans to do it, would be nice if the new structure supported future work on it.

With that in mind, based on your initial comment, wouldn't it make more sense to call windows folder win32, so that in a possible future winit uses windows in the same vein unix is planned to be used?

On another totally separate note, since this will move quite a lot of files, maybe it would be a good idea to adopt the 'newer module system' for stuff inside platform_impl? At the end of the day it's purely a preference choice, but I feel like more people are growing used to it than using mod.rss.

[thatsofia]

Isn't WinRT/UWP deprecated now? What's the point in renaming things for a dead platform?

[rockisch]

Isn't WinRT/UWP deprecated now? What's the point in renaming things for a dead platform?

...is it? Genuine question, I'm not that into Windows GUI development, so I don't really get what Microsoft's plan is behind the whole 'App SDK' stuff.

It seems like the Windows Store only opened doors for Win32 apps last year tho, so unless they deprecated WinRT in the meantime, I feel like it should still be relevant.

[ids1024]

I think UWP is basically deprecated, "WinRT" isn't, and there's work on better integrating it with win32 stuff? As part of Microsoft's "Project Reunion".

But honestly I don't entirely follow exactly what's going on with these APIs or exactly how Microsoft is using all of these terms.

[madsmtm]

Note: We intentionally don't use the platform! macro here, since this is the "starting point" where we may not know the specific platform yet.

[daxpedda]

We briefly touched this on IRC, but my preference would be to move all backends entirely out of the Winit crate and into separate crates (still a monorepo).

Though I'm not against this PR and don't mind approving it, it's probably pointless if we have consensus on the separate crates idea.