Add a handle for views

[notgull]

This MR adds a handle type specifically for views. "Views" are defined
as sub-areas of windows that graphics APIs can render into. This is
separated from Windows, which may be a key difference for some APIs.

So far this MR only implements views that wrap around windows, and views
that wrap around NSView from AppKit. Discussion must be done to
determine if this is the best way to go about this, as well as if we
should add other views.

Ref: #123

[notgull]

AI: Change name to SurfaceHandle.

[notgull]

I'm actually wondering if this isn't the right play here. Maybe just having a macOS window handle with a back-pointer to the NSWindow would work, just like how we are currently planning to do Wayland windows.

struct AppkitWindowHandle {
    ns_view: NonNull<c_void>,
    ns_window: Option<NonNull<c_void>>
}

[MarijnS95]

Glutin and GL are two independent crates

Suggested change

	/// [`glutin`]: https://crates.io/crates/gl
	/// [`glutin`]: https://crates.io/crates/glutin

[kchibisov]

I think the best way forward with this, would be to change current window handle to SurfaceHandle, and for window handle, have a way to get it from the SurfaceHandle::window_handle(&self) -> WindowHandle?

This thing should be forward compat, I think.

Also, you don't need Window that often, but if you need, you likely need both at the same time, so it's better to have the actual data(pointers, etc) to lay at the same struct and produced together (less change to fail).

[kchibisov]

This thing is technically not forward compat, since if you had e.g. Wayland in Window and with update you made a special variant for that, that won't change the enum and the code will still compile, but it won't work anymore, because the data within enum moved.

[madsmtm]

I think I'd like to wait a bit with this, I'd like to get reference-counting figured out first (#188) (if we haven't figured it out in like 2 weeks, consider this concern resolved).

I also think I agree with Kirill, at least in that I'd rather preserve the WindowHandle we have right now as-is as the surface/view handle, and rather introduce a wrapper on top that is the actual "window" handle.