Expose the main thread.

[emidoots]

There are certain situations where one needs explicit ownership of the main loop. A good example of this is Cocoa API's which must be executed on strictly the main thread, inherently any GUI libraries that operate on OS X also have this requirement.

The goal is to expose control of the main loop to the user of the package, if they so desire.

I propose exposing a channel window.MainLoopChan over which arbitrary functions (which MUST be ran on the main thread) will be sent by running windows.

This would allow for a swift communication with the window package on-demand (i.e. when the window package doesn't need to execute functions, you don't execute any, in contrast to busy-waiting glfwPollEvents and things).

At least one problematic side effect of this is that we can no longer utilize go.mobile/app because it steals the main loop entirely.

See azul3d-legacy/issues#29 for previous discussion.

[emidoots]

Something I want to clarify: This would expose the main thread but would not offer any communication with the OpenGL render loop.

[emidoots]

See also discussion in #40