OS X SDK unit tests

[1ec5]

Added an XCTest bundle to the osxsdk scheme. For now, it contains some basic tests of shared iOS/OS X code. It can easily be extended to cover more of the SDK, including UI tests via XCTUI.

Unlike what we did on iOS for #830, I’ve integrated the test bundle directly into the project that contains the SDK code, allowing us to write unit tests as opposed to just integration tests.

This PR works toward replacing KIF with XCTUI on iOS, which would eliminate the unreliability in #2734 and allow us to add better tests around user interaction and performance. I started with OS X because everything’s simpler on OS X. 😄

/cc @incanus @friedbunny @jfirebaugh

[jfirebaugh]

Yay!

[1ec5]

Travis consistently stalls on the xcodebuild test invocation. Hopefully this is something we can address by fiddling with arguments; otherwise, we may be forced to take care of #2776 first.

[friedbunny]

Running locally:

$ make xctest
build: osx/x86_64
host: osx/x86_64
libs: headless=cgl  platform=osx  asset=fs  http=nsurl  
* Recreating project...
Build settings from command line:
    SDKROOT = macosx10.11

xcodebuild: error: Scheme osxsdk is not currently configured for the test action.

make: *** [xctest] Error 66

[friedbunny]

After cleaning, xctest hangs with the same output but without the above error.

[1ec5]

xcodebuild test requires a shared scheme, but schemes don’t get generated in the first place unless you open the project in Xcode. The xcodeproj gem can generate shared schemes, but they don’t include test targets: CocoaPods/Xcodeproj#139. make itest works because it relies on a checked-in Xcode project, but I don’t want to go that route until we properly implement #3275.

[1ec5]

Hilariously, in the end, all that works is opening the project in Xcode and waiting several seconds. I tried using fswatch, but unfortunately Xcode doesn’t generate the schemes atomically. A lot of this would’ve been simpler if Xcode’s AppleScript dictionary worked as advertised.