Catch exceptions thrown during examples and highlight the failed example in Xcode

Before:
![capture 2014-06-16 at 8 14 51 am](https://cloud.githubusercontent.com/assets/147686/3282144/94c0ad5c-f4da-11e3-96f6-91c2818a2aa4.PNG)

After:
![capture 2014-06-16 at 8 13 32 am](https://cloud.githubusercontent.com/assets/147686/3282145/9ec9db3e-f4da-11e3-8996-bd83a80019b5.PNG)

1. Wraps the call to `[example run]` in a `@try`/`@catch` to intercept exceptions raised during an example.
2. Report these exceptions to XCTest using the callsite of the example.
3. Profit!

The main thing I'm not sure about is exposing `example:failedWithException:` in `QuickSpec.h` (it was so nice and clean with just one method!). Other than making it easier to write a functional test for, here's the use case for it in my project:

I'm using KIF, which raises an exception when it times out searching for a UI element on screen. KIF very nicely attaches callsite metadata to the exception that's thrown using the `SenTestFilenameKey` and `SenTestLineNumberKey` in `userInfo` (which I believe is due to the way OCUnit used exceptions to report test failures). So I have a `KIFSpec` class that derives from `QuickSpec`, and it pulls out the the file and line number from the exception in order to report the failure using the more accurate callsite information. Like this:

```swift
  override func example(example: Example!, failedWithException exception: NSException!) {
    let file = exception.userInfo["SenTestFilenameKey"] as? String
    let line = exception.userInfo["SenTestLineNumberKey"] as? Int

    if file && line {
      self.recordFailureWithDescription(exception.description, inFile: file!, atLine: line!, expected: false)
    }
    else {
      super.example(example, failedWithException: exception)
    }
  }

```

It didn't seem appropriate for `QuickSpec` to know about these keys itself, but having the ability to override the failure handling in a subclass seemed like a good compromise.
> Long story short, when bridging a Swift class into Objective-C, it seems that Swift structs are completely ignored, as if they don't even exist!

Ah yes! I've seen this myself. But I'd rather have `Callsite` be a class if that saves us a couple of lines of code. Structs are supposed to be great because they have a lower memory footprint, right? I don't think that's a real issue here, since we're not running on mobile devices.