[red-knot] make large-union benchmark slow again

[carljm]

Summary

Now that we've made the large-unions benchmark fast, let's make it slow again!

This adds a following operation (checking len) on the large union, which is slow, even though building the large union is now fast. (This is also observed in a real-world code sample.) It's slow because for every element of the union, we fetch its __len__ method and check it for compatibility with Sized.

We can make this fast by extending the grouped-types approach, as discussed in #17403, so that we can do this __len__ operation (which is identical for every literal string) just once for all literal strings, instead of once per literal string type in the union.

Until we do that, we can make this acceptably fast again for now by setting a lowish limit on union size, which we can increase in the future when we make it fast. This is what I'll do in the next PR.

Test Plan

cargo bench --bench red_knot

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[codspeed-hq]

CodSpeed Performance Report

Merging #17418 will degrade performances by 98.64%

_{Comparing cjm/unionlimit (91df0e5) with main (a1f3619)}

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]	78.9 ms	5,816.3 ms	-98.64%