Split parts of winit into separate crates

[notgull]

I recently stumbled upon #1298, which feels like a pretty good idea to me. For some of the types in this crate, they could probably be split out into a winit-types crate (preferably developed as a separate crate in the winit repo) that avoid linking to backends.

It looks like, originally, winit-types and glutin-x11-sym (for X11 types) were planned to be split into other crates. I agree with winit-types, and I can also agree with splitting global X11 resources into another crate, since there are global resources that need a single authoritative source to be managed. The rationale is similar to that of the signal-hook-registry. However, there's no harm in having several X11 shared libraries lying around following AltF02/x11-rs#165

I think that winit-types and a hypothetical winit-xlib crate would be good candidates to be split off of winit. Is there any other room for splitting here? It feels like anything further would require us to slice and dice the platform_impl module, which just sounds like a pain. On top of that, the more we split off, the larger the dependency tree gets, and we have to consider if the gains in compartmentalization are worth it.

Would probably need to wait until after #2662

[notgull]

I've created an implementation of the winit-Xlib crate mentioned above, here: https://github.com/notgull/tiny-xlib

[kchibisov]

I think only X11 has such issues especially given that we use X11 unsafe stuff in public APIs. Other types are not that useful.