Cleanup: Migrate run-fail tests in src/test/ui from error-pattern to check-run-results

[tmiasko]

As tests are moved from src/test/run-fail to src/test/ui #65440 the meaning
of // error-pattern in ui tests becomes overloaded , since tests in
src/test/run-fail match error patterns to executable output while
src/test/ui tests match them to compiler output.

The changes in #65759 enable such overloaded use: if test is expected to
compile successfully and will be run, the patterns are matched to executable
output, otherwise patterns are matched to the compiler output.

@petrochenkov suggested that it might be preferable to migrate those test to use check-run-result instead.

1. Decide if check-run-result is preferable over error-pattern for run-fail tests in ui.
2. Migrate run fail tests to use check-run-result.
3. Remove support for overloaded meaning of error-pattern.

[petrochenkov]

Another option is to do "check-run-results" automatically for all run-* tests and create the .run.stderr / .run.stdout files only if the output is not empty.

[clubby789]

Based on the results of #133460, I'm not sure how worth it this is, as I think tests where we care about the exact stderr are fairly rare. We would definitely need a lot more normalization before doing this automatically

[jieyouxu]

See also Audit {check-run-results, error-pattern, check-stdout, normalize-*, dont-check-compiler-*, run-rustfix, rustfix-only-machine-applicable, forbid-output} family of directives.

[jieyouxu]

compiletest triage: I'm not convinced switching error-pattern run-fail ui tests to use only the current form of check-run-results is an improvement over error-pattern unconditionally. If anything, it would be a regression to flaky tests in many cases that are sensitive to exact run stdout/stderr (line numbers, backtraces that can depend on platform-specific unwind mechanism, concrete addresses, version numbers, etc.).

I would be in favor of auditing some of these run-fail tests and sparingly add check-run-results if the exact run stderr/stdout is critical for the intention of the test, but not in a blanket fashion. As such, I'm going to close this issue in favor of a more concrete audit issue.