sort:Add sort long-line locale benchmark

[mattsu2020]

What changed

• Add a UTF-8 locale benchmark for sorting 26 long ASCII lines.
• Use 1 MiB per line and the same core knobs as the reported workload: --parallel 1 --buffer-size 8G.

Why

This covers the long-line locale collation case discussed in #12144 and #12138 without adding a multi-GiB benchmark input.

Validation

• cargo check -p uu_sort --benches
• cargo bench -p uu_sort --bench sort_locale_utf8_bench sort_long_ascii_lines_utf8_locale

Observed local benchmark result:

sort_long_ascii_lines_utf8_locale/1048576
mean 7.782 ms, median 7.226 ms

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tail/retry. tests/tail/retry is passing on 'main'. Maybe you have to rebase?
Note: The gnu test tests/basenc/bounded-memory is now being skipped but was previously passing.

[codspeed-hq]

Merging this PR will degrade performance by 4.66%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 1 regressed benchmark
✅ 310 untouched benchmarks
🆕 2 new benchmarks
⏩ 46 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	sort_ascii_utf8_locale	15.4 ms	16.1 ms	-4.66%
🆕	Simulation	sort_long_ascii_lines_utf8_locale[1048576]	N/A	56 ms	N/A
🆕	Memory	sort_long_ascii_lines_utf8_locale[1048576]	N/A	36 MB	N/A

---

_{Comparing mattsu2020:codex/sort-long-line-benchmark (acc9a16) with main (c23dc67)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩