Don't log a test case as having failed expectedly after it has already experienced
an unexpected failure.

Before, we were doing exactly what the comment said we shouldn't do:
overriding `failureWasExpected` if `failureWasExpected` was `NO`,
indicating that we had failed unexpectedly.
Simplify the signature of SLTest's exception-logging method. (refs #72)
`SLTest` and `SLTestController` use `SLLogger` to log exceptions occurring during tests.
(refs #72)

This entails moving `SLTest`'s exception logging routine to `SLLogger`,
while the determination of whether the exception was expected,
and whether call site information should be attached, remains in `SLTest`.

This change is made to unify `SLTestController`'s exception logging with
that of `SLTest`.

Because `SLTest` and `SLTestController` no longer log exception error messages
directly--they call `-[SLLogger logException:expected:]` rather than `-logError:`--
in order to continue to test that those error messages include call site information,
the `SLTestTests`' logger mock must become a partial mock (so that the actual
logger will call `-logError:`). It was actually unnecessary to stub the logger
for the purposes of "preventing the framework from trying to talk to UIAutomation,"
as the comment said--that is accomplished by stubbing the terminal below that.
If a test fails in both test set-up and tear-down, both exceptions will be logged.

We had previously ignored the second exception on the basis that it was superfluous
--expected somehow on the basis that set-up had already failed. But,
if a test fails in both test *case* set-up and tear-down, we log both those exceptions;
and it's probably better to err on the side of more information.

Since there is potentially both an exception from test set-up _and_ an exception
from test tear-down to log, `-[SLTest runAndReportNumExecuted:failed:failedUnexpectedly:]`
can no longer throw such exceptions for the test controller to log, but rather logs those
exceptions itself and returns `YES` or `NO` to indicate whether the test finished or aborted.
This actually makes the test execution structure a fair bit simpler.

Because `SLTest` is now logging all test exceptions itself,
it no longer needs to expose `+exceptionWasExpected:`.
Test termination is now reported as a message, not an error. (refs #72)

Termination is a status logged _after_ the error that caused termination
to occur--calling termination an error too is categorically confusing.
Calling termination an error would have made it difficult for
`subliminal_uialog_to_junit` to determine where a test started and began
--it's simpler if regular messages ("test started" and "test terminated abnormally")
bookend the error.
Improve the performance of `subliminal_uialog_to_junit`.

By only processing one regular expression match per iteration of the loop
(the successful match), and by only writing the XML tree to disk when complete
(rather than after every element appended to the tree).
`subliminal_uialog_to_unit` now logs errors that cause tests to abort. (refs #72)

These errors occur at the `testsuite` level (in suite set-up or tear-down),
but only `testcase` elements may contain failures or errors (because JUnit tests
don't have such set-up and tear-down), so we create dummy `testcase` elements
to report these errors. Because, for each test, there are two potential exceptions
to log at the `testsuite` level (one during set-up, and one during tear-down),
errors are now logged when they occur rather than when their enclosing scope
closes.
`subliminal_uialog_to_unit` logs uncaught exceptions as test case _or_ test errors.
(fixes #72)

As appropriate.
Merge pull request #73 from inkling/jeff/72_report_suite_level_failures_in_JUnit

Massive improvements to error reporting and JUnit generation.