Previously, `softbuffer` wouldn't successfully build on its own on Windows; the examples only worked because dependencies happened to enable the needed features.
As documented in the new safety comment, providing `&mut` access to an
inner component about which there are consistency invariants is unsafe,
because `&mut` is sufficient for a caller to completely replace the
value (using assignment or `std::mem::swap()`).
Luckily, when `softbuffer` is used with `winit`, no `&mut` access is
needed. However, other windowing libraries such as `glfw` and `sdl2` do
have `&mut` methods, so this method can't simply be removed.
This is a breaking change since it makes a previously safe function
unsafe, and should not be published without a major version bump
(i.e. to `0.2.0` or higher).
This will allow code which works with windows generically (such as an
event loop which can work with `softbuffer` or another graphics library)
to be able to access the underlying window without knowing about
`softbuffer` in particular.
A limitation of this implementation is that it can't coexist with anything which creates a canvas context other than `CanvasRenderingContext2D`, since only one context can exist per canvas.
