[red-knot] make large-union benchmark more challenging

[carljm]

Summary

Now that we've fixed one large source of constant overhead in building large unions of literals, we can afford to make this benchmark a bit nastier, by letting the union get 8x as big (up to 2048 elements, as opposed to just 256 before). The motivation for doing this is so that the benchmark can more clearly show the distinction between constant-overhead optimizations and algorithmic-complexity improvements (which are relatively more important the larger the union in the benchmark gets.)

We expect the largest unions (from large code-generated enums) that we need to support may be around 4k or 5k elements, so ideally we'd increase the benchmark to that size, but at the moment that still makes the benchmark too slow.

Test Plan

cargo bench --bench red_knot

[codspeed-hq]

CodSpeed Performance Report

Merging #17416 will degrade performances by 96.93%

_{Comparing cjm/bigunionbench (3ee7bf3) with main (807a8a7)}

Summary

❌ 1 regressions
✅ 32 untouched benchmarks

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

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	red_knot_micro[many_string_assignments]	98.6 ms	3,211.1 ms	-96.93%

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.