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.
Ah yes, I knew there was something that I forgot to include in my pull request notes!

This was exactly the approach I took at first. But when trying to make sure this feature worked for both Swift and Objective-C specs, I discovered that the generated Objective-C header was just completely ignoring the `callsite` parameter.

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! At this point there seemed to be two options: either change `Callsite` from a struct to an `@objc`-bridged class, or create these simple computed properties that expose `file` and `line` as types that are visible to Objective-C. I opted for the latter option.

Does that make sense?

Also I'm happy to rename the properties to remove the `_` prefix.