Tracking issue for macOS threading issues

macOS requires all GUI code to be on the first thread created by the OS. The Go runtime moves goroutines between OS threads unless `runtime.LockOSThread()` is called. But there is no formally documented way to ensure that a goroutine is locked to the first OS thread, as opposed to the thread the goroutine happens to be running on at the moment.

Go currently *does* allow this, though: call `runtime.LockOSThread()` from `init()`. Of course, there are catches that I will need to document to be able to do this and make sure it doesn't fail, and Go 1.10's change to make `runtime.LockOSThread()` nested will fix some of them. And the biggest issue is that this isn't really documented yet, meaning I didn't feel comfortable relying on it. Other similar packages (like shiny) did, so...

I've filed an issue on Go asking for this feature to be documented — golang/go#23112. However, fixing this in package ui is not contingent on that issue being closed. package ui documentation *might* be.

The other benefit to this is that we won't need undocumented API calls or mach_override hacks.

You can monitor this issue to see when I have implemented the necessary fixes. IDK if it will require an API change or not.