Support a "known issue" test result type

[echeran]

We should add a "known issue" result type. It would correspond to when a test input for a platform/library matches criteria for an existing bug filed in the upstream project of the platform.

The benefit of having the result type is to better categorize / triage the results of our executor implementations, as we continue to update and improve them. Currently, we have test failures, and those failures could be the result of: the library (unknown bug), the library (known bug), or a deficiency in our executor. Sometimes, a known issue causes a systematic set of many test failures.

For the purposes of our project, it would help instill confidence in our self-assessment of correct executor implementation work to not include known bugs in the set of test failures.

[sven-oly]

PR #256 is moving in this direction, identifying some known issues in test failures, errors, and unsupported. It shows these in DateTime format results as orange bars. It also has some classification of details.

Next steps:

1. build better ways of identifying test results that are known issues.
2. add mechanism to find the same test across multiple platforms and ICU versions, using the hexhash value.

[sven-oly]

Progress made with known issues in Date/Time formatting in PR #329, handling "alternate" vs. "standard" formatting results.

[sffc]

The WG decided on the following plan: "Suggested path forward: make a clear interface for the Python known issue function and refactor it to a separate module/file, so that it could be refactored to be provided as a CLI argument later."

We already have such a file: https://github.com/unicode-org/conformance/blob/main/verifier/check_known_issues.py

The main function is check_issues. It has a clear interface which could be refactored later.

So I'm closing this as fixed.