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.
I'm happy to add some comments for those properties if you think it would be helpful. In the meantime, that's why I put the explicit `@objc` annotation on each property: so it was hopefully a little clearer that they were being exposed for use in Objective-C.

If you're happy to stay with the properties as they are, I could perhaps move them into a Swift extension? e.g.

```swift
// Expose Callsite properties to Objective-C
extension Example {
  var file: String { return _callsite.file }
  var line: Int { return _callsite.line }
}
```