Error handling for expected likely subtag errors

[echeran]

Some of the test cases for likely subtags are supposed to fail. The source test data encodes this information.

We need to decide a canonical error representation during our testing. CLDR defines ways to handle such an error:

Signalling an error can be done in various ways, depending on the most consistent approach for APIs in the module. For example:

raise an exception
return an error value (such as null)
return the input (with missing fields)
return the input, but "Zzzz", and/or "ZZ" substituted for empty fields.
"und"

Whichever way we decide to handle it, we need to update our executors, which will also hopefully decrease the number of test failures.

[sffc]

For likely subtags, ICU4X has this enum:

pub enum TransformResult {
    Modified,
    Unmodified,
}

Let's supposed that enum has a third variant: NoData

Code to create a handled exception would look something like this:

let mut locale = // get from input
let result = icu4x_locale_expander.maximize(&mut locale);
if matches!(result, TransformResult::NoData) {
  // return handled exception
} else {
  // return a completed result
}

[sffc]

Also see my comment in #242

I think there are 3 ways to solve this issue:

1. Add code to the executors to detect when a minimize/maximize operation failed: for example, if the output is unmodified and there were fewer than 3 subtags in a maximize operation. In those cases, the executor should return some sort of failure status, and the verifier should detect that status and return a successful status.
2. Consider it a Known Issue when an executor does not have the capability to distinguish a likely subtags operation that did not run to completion, and if an implementation adds such an API (as I sketched out above in ICU4X) it can start passing those tests
3. Change the test expectations to be input == output, removing the "expected exception" case entirely. Implementations that do handle the exception should return input as output.