Consider switching to winit for WASM target

[alvinhochun]

winit supports both stdweb and web-sys by using a <canvas> element for the "window". Using winit for WASM may simplify some of the canvas handling code as glutin also uses winit behind the the scene (however glutin itself does not work on WASM so only the winit parts can be shared).

Potential blockers:

• Works only with PointerEvent and not MouseEvent (fixed on master by Web: Use mouse events instead of pointer events if the latter isn't supported rust-windowing/winit#1630 but unreleased)
• Mouse capturing (Mouse/pointer not captured when dragging out of the canvas area on web target rust-windowing/winit#1660)
• Canvas size is fixed and can't use CSS layout (Allow canvas size to be controlled by page layout on web target rust-windowing/winit#1661)
• Change of hidpi factor not handled (Handle scale factor change on web-sys backend rust-windowing/winit#1690)
• Cleanup on event loop end (Web backend does not handle ControlFlow::Exit nicely rust-windowing/winit#1688)
• Touch event support on web (Implement touch handling on web target(s) rust-windowing/winit#1673)
• Able to start event loop on web and return to caller (Suggestion: Add a web-only event loop run API that returns to caller rust-windowing/winit#1714)
• Update winit and change kiss3d code flow and API to use event loop v2

[sebcrozet]

Sounds like a great idea.

Update winit and change kiss3d code flow and API to use event loop v2

As you suggested in #252 (comment) we should probably just deprecate Window::render and always use Window::render_loop.

[alvinhochun]

It's not absolutely necessary to deprecate Window::render, but it does mean there will be two separate code paths for handling the event loop since Window::render_loop will no longer use poll_events.