Throw instead of failing from code in UITestHelpers

In this WWDC 2020 session, Apple's Kelly Keenan shares this recommendation:

In my tests, the rule is that I always throw instead of assert from shared code. The reason is because the shared code is being run from many tests, and in some of those tests, I may purposely be testing negative test cases to ensure something hidden isn't shown or to force an error dialog to appear for testing purposes.

I couldn't agree more. I picture UITestHelpers as a set of sharp tools that test authors can easily fit in their scenarios. The less assumptions it makes and the less constrains it puts on the flow, the better.

To make this happen, we'd have to define some kind of custom error for our framework to throw.

I think a neat place to start might be a nested type, like:

extension XCUIElement {

	enum ElementError: Equatable, Error {
	    case doesNotSupportTextManipulation
	}
}

With this type, we could update the following code (taken from this PR) from:

public func clearText() {
    guard let stringValue = self.value as? String else {
        XCTFail("Tried to clear and enter text into a non string value")
        return
    }

to:

public func clearText() throws {
    guard let stringValue = self.value as? String else {
		throw XCUIElement.ElementError.doesNotSupportTextManipulation
    }

Start by locating UITestHelpers and the XCUIElement.clearText implementation referenced in the issue and linked PR. Trace its current XCTFail path and the affected test callers; done means shared helper failures throw a custom XCUIElement error instead of asserting, with the UI test suite still compiling and passing.