Should we get rid of #[non_exhaustive] on variants? #215

Our RawWindowHandle enum is #[non_exhaustive] - this makes perfect sense, since we might add support for other platforms in the future. But the variants of that enum are also #[non_exhaustive], and this might be overly conservative?

After #214, f we got rid of the #[non_exhaustive], we could allow users to construct the variant directly, which is kinda nice, especially if we want to view RawWindowHandle as "just plain old data":

// Current
let handle = RawWindowHandle::new_uikit(ui_view);
match handle.as_raw() {
    RawWindowHandle::UiKit { ui_view, .. } => {
        // ...
    },
    _ => todo!(),
}

// After
let handle = RawWindowHandle::UiKit { ui_view };
//                            ^^^^^ no need for a helper constructor method
match handle.as_raw() {
    RawWindowHandle::UiKit { ui_view } => {
        //                          ^ no need for ", .."
        // ...
    },
    _ => todo!(),
}

A downside of that would be that if we ever wanted to introduce new fields, we'd need to introduce a new variant:

let handle = unsafe { WindowHandle::from_raw(RawWindowHandle::UiKit2 { ui_view, other_stuff }) };

Which means that consumers would have to be updated to handle both before producers could use the new variant.

How valuable is it to keep this door open?