Make SLTextField setText work with more strings

Updates SLTextField's setText method so that it can handle
strings that include characters that do not appear on the
software keyboard in the software keyboard's default state.
Make SLTextField clear text before setting new text

When SLTextField takes the typeString path in its setText method,
it also needs to explicitly clear whatever text happens to be
in the text field already before starting typing.  Otherwise
the typeString call will just append the new text to the end
of whatever's currently in the text field (unless we luck out
with clearsOnBeginEditing).

This commit also modifies the testSetSearchBarText test case
to make sure that it exercises the scenario that previously
caused bad behavior.
Merge pull request #52 from inkling/aegolden/update_settext

Make SLTextField setText work with more strings
Distinguish between various issues in exit status

Causes subliminal-test to exit with different non-zero exit
status numbers depending on what went wrong.

If tests did not complete for any reason, we'll still exit
with status 1.

If tests completed but there were test case failures, then
we'll exit with status 2.

If tests completed but there were focused tests, we'll exit
with status 3.
Merge pull request #54 from inkling/aegolden/misc_fixes

Distinguish between various issues in exit status
Add SLStatusBar element and test cases
Merge pull request #55 from inkling/leon/statusbar

Add SLStatusBar element and test cases
Restart instruments if it fails to launch the target.

This will hopefully resolve failures that we see somewhat more than occasionally
on Travis such as https://travis-ci.org/inkling/Subliminal/builds/9926376#L1189,
where--within the same run--instruments may fail to launch the app on one platform
and then run the others successfully. Since this seems to be a momentary failure,
instruments will hopefully succeed if we retry, after a short delay for good measure.
We've not been able to reproduce this error locally or in other CI environments,
unfortunately. If this fix does not successfully work around the problem we will try
something else.
Restart instruments only if it did not launch the target.

As evinced not only by it returning an error, but by not having written a log.
instruments has only been observed to return an error if it fails to launch the target,
but we should only ever restart it if it didn't run at all, to avoid overwriting results.
Restore `-[SLTextField setText:]`'s use of `-[SLKeyboard typeString:]` in all cases.

This effectively reverts commit dc491fc72218a4d1c849f27a5482ec9adac620c9.
The UIAutomation bug described by that commit could not be reproduced:
`UIAKeyboard.typeString` appears to change the keyplane as necessary
to type special characters, across all device type and SDK combinations.

Pending further bug reports, using `-typeString:` is to be preferred
because it is simpler, because it most accurately simulates user interaction,
and because if there was a bug discouraging the use of `-typeString:`, a workaround
would have to be implemented not just in `-[SLTextField setText:]` but also
in `-setText:` as implemented by `SLWebTextField`, `SLTextView`, and `SLWebTextView`.

A test case has been added to verify that `-[SLKeyboard typeString:]` changes
the keyplane as necessary to type special characters.
Create a specific test case for `-[SLTextField setText:]` clearing the current text.
Make logic around text fields and views becoming first responder consistent.
All text fields and views now clear their current text before setting new text.
Clarify the use of `SLWebTextView` to represent HTML text areas.

Despite UIAutomation representing such DOM elements by instances of `UIATextField`.
Slightly relax the `SLTerminalTest` timeouts.

I think that the existing variability only accounted for the evaluation of the condition,
and an additional evaluation delay is needed for the wait function as a whole. That would
tally with this Travis failure: https://travis-ci.org/inkling/Subliminal/builds/10175832#L1863.
Clarify the documentation of `SLWaitUntilTrue`.
The tests of `SLWaitUntilTrue` now all take into account the delay in that macro retrying,
as appropriate. (refs #53)
All tests concerning timeouts now assert that Subliminal waits for *at least* the specified
timeout. (fixes #53)

While there is variability in timeouts, that variability should always be positive
--Subliminal should never stop waiting while there is time remaining.
Properly account for the delay inherent in asking UIAutomation to look up an element's value.
Merge pull request #57 from inkling/jeff/restart_instruments

Restart instruments if it fails to launch the target.