Proposal: Remove all the cfg guards.

[thomcc]

Right now platform-specific modules and variants are only on platforms that are known to support them. We probably should expose them more broadly, probably everywhere.

Upsides:

1. Allows much wider range of support. Concretely:
   • This allows code to support custom/json targets, so long as the windowing code can provide the right handle, and other libraries can consume it.
   • This allows support for various unixes that can support e.g. X11 but are not in the set of linux | dragonfly | freebsd | netbsd | openbsd (the current cfg). For some examples, Solaris is left out by the current cfg, or even macOS, which can use X11 (and xlib — in College I even got XCFE running under it) if the user has XQuartz installed.
   • Mac Catalyst would be able to provide either RawWindowHandle::MacOS or RawWindowHandle::IOS, which reflects the fact that it can use either AppKit or UIKit (despite being target_os = "ios").
   • I don't really know for certain, but I'd guess that there are some weird windows configurations that would benefit from this too. Certainly stuff like XBox, but that's probably covered by "json target".
2. Downstream code doesn't have to ensure that the cfgs they use match (or are a subset of) the ones raw-window-handle uses.

Downsides:

1. It means that removing a handle type is a breaking change even if it's only usable on an OS nobody uses (or that isn't supported by Rust).

   • This is the biggest downside, but in practice the set of windowing handle types is pretty small, and we can just deprecate them instead if it's an issue. It's also not like a single struct definition really hurts anything.

2. It's less clear to code that's consuming raw handles which combinations of handle variants and OSes are possible.

   • That said, this lack of clarity reflects reality, where you can do dumb things like run XFCE on macOS under XQuartz (I don't know if this is still possible, and would assume it's not, although I did compile and run Xlib-using C code for macOS a few months ago, so that much definitely is still possible).
   • I don't think we consider the set of cfgs we use to be part of the stable API anyway, so this is likely a moot point.
   • To a certain extent, I think it's still pretty clear (you can get RawWindowHandle::Xlib anywhere someone can get xlib running) this can be addressed by documentation.

3. It forces us to continue using fully opaque types in all supported backends.

   • TBH I think this is actually a good thing, as it keeps things reusable (using objc types directly would be a problem for code that uses fruity for example).

4. Slightly more code sent to rustc == slightly slower compiles.

   • This crate is teeny and this adds no deps though, so it doesn't matter.