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.
Yeah you're right, probably belongs in a different PR. It's just that when writing a Quick functional test, having a call to `XCTFail` right in there was breaking my suspension of disbelief!

```swift
it("catches unhandled exceptions", {
    self.expected.raise()
    XCTFail("expected test execution not to continue after raised exception") // ugh, I don't want to see no ugly `XCT` prefix in my beautiful Quick spec!
}, file: self.exampleCallsite.file, line: self.exampleCallsite.line)
```