Add a channel for winit events

[asajeffrey]

Glutin provides its event stream as an iterator rather than on a channel, which means we can't select on it. This causes problems of merging the glutin event stream with the servo event stream, in particular for the shutdown event (see, e.g. #11307).

We'd like to move to a model where glutin is providing events over a channel, and as long as we're prepared to dedicate a thread to it, we can just read events from the glutin iterator, and write them into a channel.

This should simplify our code quite a bit, e.g. we can probably get rid of CompositorProxy at that point.

cc @metajack

[metajack]

@tomaka If Glutin provided a channel interfaces instead of only an iterator, then we could remove the need for wakeup events completely. This seems like a much better way to do things, and certainly more in tune with how rust normally works. What do you think?

[tomaka]

@metajack Does that mean glutin will need to spawn a background thread on Linux and OS X as well?
I don't know for OS X, but for Linux it's the fact that the user calls poll_events or wait_events that asks X11 for events. The events won't magically go in the channel.

[metajack]

@tomaka I believe so. The Windows code already does this, so it's pretty easy to make the callback stuff the event into a channel. Perhaps on Linux and OS X this could done lazily only if you call the function to get the receiver. That way you only pay for the extra thread if you actually use the channel interface.

[atouchet]

Is this still relevant now that Glutin has been removed?

[jdm]

yes; the events come from winit instead of glutin.