when the simulator fails to start, display the failure message.

This will give us a helpful hint about what's going wrong.

Before, it might look like this ...

```
  0) -[TEST_BUNDLE FAILED_TO_START] (TestProject-LibraryTests2.octest)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
There was a problem starting the test bundle: Failed to uninstall the test host app 'com.facebook.TestProject-TestHost' before running tests.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

Now, it will look like this ...

```
  0) -[TEST_BUNDLE FAILED_TO_START] (TestProject-LibraryTests2.octest)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
There was a problem starting the test bundle: Failed to uninstall the test host app 'com.facebook.TestProject-TestHost' before running tests: The application that opened iOS Simulator failed to send all of the required information (sessionUUID, sdkRoot, deviceInfo).
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
extracting `buildSettingsWithAction` block into method.
when writing errors to stderr, do so after reporters are closed.

We'll now write any error messages at the last possible moment, after
reporter tasks have been closed out.  This prevents bugs where stderr
(from xctool) is interleaved between output from the reporters (which
run as separate processes.  By waiting until all reporter processes have
been closed, we can guaranteed that our output doesn't get jumbled.
when xcodebuild -showBuildSettings fails, display its error message.

xcodebuild will usually give us a nice-enough error message on STDERR
when it's going to fail.  We should show that.

e.g., when calling xctool with a bogus -destination value, we'll now get --

```
[Info] Loading settings for scheme 'TestProject-Library' ... (98 ms)

ERROR: option 'Destination' requires at least one parameter of the form 'key=value'
```

This also fixes the bug where xctool would crash when bogus values for
-destination were supplied.
adding common method to return a DTiPhoneSimulatorSessionConfig

We use this to run the application tests, but also to run the
mobile-installation-helper app.  Let's have one common function that
both code paths can use.
to set the simulator device, use setSimulatedDeviceInfoName:

This removes the hack where we would set the 'SimulateDevice'
user-default as a way of selecting the simulator device.

NOTE: This moves us to a broken state in the interim.  For now, the only
way to run application tests is to supply -destination.  It will fail
without that.

Later diffs will fix this problem.
removing the -simulator arguments in favor of -destination.

-simulator [iphone|ipad] used to let you select the device family.  This
is not as useful any more, since there are several possible devices in
each family.

People should just use -destination since it's far more specific.
removing the -test-sdk option in favor of -destination

xcodebuild will accept multiple -destination arguments.  Going forward,
the preferred way of setting the test SDK is like ...

```
xctool ... test \
  -destination 'name=iPhone Retina (3.5-inch),OS=6.0' \
  -destination 'name=iPhone Retina (3.5-inch),OS=7.0'
```
adding DestinationInfo for parsing -destination strings.

This isn't plugged into anything yet but it parses.
when consuming args, allow MapToSelector options to return errors.

Previously, when mapping arguments to selectors, the selector could only
accept a single argument.  e.g., @selector(setFoo:).

Now, you can optionally map to a selector like @selector(setFoo:withError:),
and the second param can be an out parameter for an error message.
Options now uses DestinationInfo to store the -destination value.

In later diffs, we'll add the rest of the plumbing to pull
DestinationInfo all the way through.
pull DestinationInfo thru to the end; it knows cpuType + deviceName

We used to have a bunch of extra plumbing to carry the deviceName and
cpuType values all way into the OCUnitTestRunner and
TestableExecutionInfo.  Now we just pass along DestinationInfo.

NOTE: This temporarily breaks running 64-bit tests, as
`-[DestinationInfo cpuTypeOrImpliedCpuType]` will always return i386.
We'll fix this in a later diff.
for otest-query, use a non-existent dir for CFFIXED_USER_HOME

I've noticed that otest-query-osx can fail if the CFFIXED_USER_HOME dir
exists at all. Instead of querying the test bundle, otest-query was
triggering an actual test run. I don't know the exact reason behind
that, but if the directory never exists... it works everytime.