Gate non-wasm32 winit features behind flags.

[TannerRogalsky]

Let me state, up front, that I would not be upset if this PR were declined. I recognize that it makes some decisions that I did not consult anyone on.

Motivation: these changes (along with #1117 and #1118) allow the winit "native" shell to compile and run on the wasm32-unknown-unknown target. This presents a homogeneous and, IMO, very pleasant development target for native/web cross-platform Iced GUIs.

It requires that a custom event loop is run on wasm32 platforms. Personally, I think that that is acceptable. Winit's basic event loop does work on wasm32-unknown-unknown but it is not particularly pretty and EventLoopExtRunReturn is not implemented (on which Iced currently depends) is not implemented. I'm of the opinion that this is fine: the requirement that users implement their own event loop on web seems like a reasonable tradeoff for using a native shell on a platform that is not really native.

It does not introduce any changes to existing users of the crate on non wasm platforms.

[hecrj]

I am guessing most of these will be fixed by hecrj/window_clipboard#18 once it is merged and released.

I think it'd be great to offer an Application implementation for Wasm out of the box too. Maybe we conditionally compile with run_return only on native platforms.

[TannerRogalsky]

I can certainly appreciate that. I find that the way that winit implements the "does not return" event loop via an uncaught exception to be not acceptable for my use cases. But providing that option to users would be absolutely an improvement.

I'll leave this open for reference and/or discussion. Feel free to close as you see fit and thanks for the consideration!

[hecrj]

Closing since this should be addressed by hecrj/window_clipboard#18 and #1096.