This PR reverts RUST-147622 for several reasons:
1. The RUST-147622 PR would format the generated core library code using
an arbitrary `rustfmt` picked up from `PATH`, which will cause
hard-to-debug failures when the `rustfmt` used to format the
generated unicode data code versus the `rustfmt` used to format the
in-tree library code.
2. Previously, the `unicode-table-generator` tests were not run under CI
as part of `coretests`, and since for `x86_64-gnu-aux` job we run
library `coretests` with `miri`, the generated tests unfortunately
caused an unacceptably large Merge CI time regression from ~2 hours
to ~3.5 hours, making it the slowest Merge CI job (and thus the new
bottleneck).
3. This PR also has an unintended effect of causing a diagnostic
regression (RUST-148387), though that's mostly an edge case not
properly handled by `rustc` diagnostics.
Given that these are three distinct causes with non-trivial fixes, I'm
proposing to revert this PR to return us to baseline. This is not
prejudice against relanding the changes with these issues addressed, but
to alleviate time pressure to address these non-trivial issues.
Instead of generating a standalone executable to test `unicode_data`,
generate normal tests in `coretests`. This ensures tests are always
generated, and will be run as part of the normal testsuite.
Also change the generated tests to loop over lookup tables, rather than
generating a separate `assert_eq!()` statement for every codepoint. The
old approach produced a massive (20,000 lines plus) file which took
minutes to compile!