Migrate iOS and OS X from libuv to GCD

[1ec5]

We should move the iOS and OS X SDKs from libuv to GCD. We’ll need to reimplement mbgl::util::RunLoop, mbgl::util::Timer, and mbgl::util::AsyncTask.

/cc @tmpsantos

[tmpsantos]

Any volunteer to do something similar for Android? /cc @zugaldia @bleege

[mb12]

This will be a high impact project for Android in terms of increasing reliability across a range of devices since it would allow MapView to be implemented as a GLSurfaceView and get rid of all the calls to eglCreateContext, eglSwapBuffers etc. Please refer to the following issue for more details.

#1662

Given the high impact, it makes more sense to do this project for Android first instead of iOS.

[zugaldia]

Corresponding Android effort ticketed: #3440

[1ec5]

Some additional context in #3139 and #2909 (comment).

[tmpsantos]

As a reference, this is how it was done for Qt: f5cb832

Note that on the RunLoop, RunLoop::addWatch and RunLoop::removeWatch is only needed if you want to support libcurl as network backend.

[jfirebaugh]

I think CFRunLoop or NSRunLoop is going to be a better fit than GCD for how mbgl's RunLoop and Thread are currently structured.

@1ec5 Do you know particular reasons whether CFRunLoop or NSRunLoop should be preferred over the other for mbgl?

[1ec5]

At a quick glance, the biggest difference between the two is that CFRunLoop is a C API that follows Core Foundation / Carbon memory management conventions, while NSRunLoop is an Objective-C API that follows Cocoa conventions. Since we’re able to write the adapter in Objective-C++, either would technically work. Much like the CFURL / NSURL choice, I’m guessing it comes down to configurability versus elegance.

[jfirebaugh]

This is now included in #2909.