Fix Implicitly Unwrapped nil value error in `XcodeSpec`

<i> Related to #206 </i>

When running `otool` in `XcodeSpec`, [the `value` of the `first` of the stream is implicitly unwrapped](https://github.com/Carthage/Carthage/blob/9368c474f195c91ac7d4b5c1ee3150bacec67f36/CarthageKitTests/XcodeSpec.swift#L74-77).

But, if `otool` hits an error, then `first()` returns a `.Failure`, whose `value()` returns `nil`, leading to `fatal error: unexpectedly found nil while unwrapping an Optional value`.

So, let's type `output` as `NSString!` and add a Nimble matcher to expect it not to be `nil`.

### Tests

The pull [successfully matches](https://travis-ci.org/jdhealy/Carthage/builds/43757279#L989) in [the case where `otool` fails](https://github.com/jdhealy/Carthage/commit/a8e7eaae8944c1513591d4c19d2544f3ec1a7522#diff-62e2145e544df11b64e87aebf67deb56R32).

It [doesn't hit that matcher when `output` isn't `nil` and then intentionally crashes :grimacing:](https://travis-ci.org/jdhealy/Carthage/builds/43760270#L999), [because I told it to exit](https://github.com/jdhealy/Carthage/commit/f3f679371bcc360e2527edd33d36c073259444c4#diff-62e2145e544df11b64e87aebf67deb56R39).
- - - 

This still doesn't explain all the weirdness of #206, so expect more in there…
I agree about avoiding implicitly-unwrapped options, in general. But, typing it as an `NSString!` allows us to mostly mitigate that risk by [checking for `nil` with Nimble in the next statement](https://github.com/Carthage/Carthage/pull/209/files#diff-62e2145e544df11b64e87aebf67deb56R87), which I'd argue is safe enough for simple test code.

Though I suppose we could use a `switch` statement like this:
```swift
switch output {
	case .Some(let output):
		expect(output).to(contain("architecture i386"))
	case .None(let output):
		// output is of type Void aka Empty tuple «()»
		// FIXME: make the following line less terrible…
		expect({ (Void) -> Bool in return true }(output)).to(beFalse())
}
```