[ty] lower MAX_RECURSIVE_UNION_LITERALS (#23521)

## Summary

This is a simpler approach to the performance issues mentioned in
#23520.

isort's profiling results suggested that #22794 added a slow-converging
calculation rather than adding a specific hotspot to the type inferer.
What makes type inference for loop variables more troublesome than other
types of type inference is the calculation of reachability.
For other types, such as implicit attribute type inference, reachability
analysis is not performed for each attribute binding (reverted due to
performance issues: #20128,
astral-sh/ty#2117). They are all treated as
reachable.
Loop variables perform this heavy calculation (omitting reachability
analysis from the `LoopHeader` branch of `infer_loop_header_definition`
and `place_from_bindings_impl` will significantly improve performance).
It appears that slow convergence for one variable in a loop block will
also slow down the inference of all other definitions in the block that
depend on it.

To alleviate the issue, this PR reduces the value of
`MAX_RECURSIVE_UNION_LITERALS` from 10 to 5. This will result in faster
convergence when the loop variable grows like `Literal[0, 1, ...]`.
Local measurements show that this PR alone improved the isort inspection
time by about 37%.
I chose 5 as the new value because I felt it offered a good balance
between type inference precision and performance, based on the following
measurement results:

| Threshold | Mean | vs 10 |
|-----------|--------|---------|
| 4         | 0.89s  | -38%        |
| 5         | 0.91s  | -37%        |
| 6         | 1.05s  | -27%        |
| 7         | 1.06s  | -27%        |
| 8         | 1.23s  | -14%        |
| 9         | 1.26s  | -13%        |
| 10 (current)    | 1.43s  | — |

It has been observed that this PR and another mitigation, #23520, are
compatible, resulting in a total performance recovery of about 40-50%.

## Test Plan

N/A

Author: mtshiba

crates/ty_python_semantic/resources/mdtest/call/union.md

@@ -299,16 +299,16 @@ class RecursiveAttr2:
         self.i = 0
 
     def update(self):
-        self.i = (self.i + 1) % 9
+        self.i = (self.i + 1) % 4
 
-reveal_type(RecursiveAttr2().i)  # revealed: Unknown | Literal[0, 1, 2, 3, 4, 5, 6, 7, 8]
+reveal_type(RecursiveAttr2().i)  # revealed: Unknown | Literal[0, 1, 2, 3]
 
 class RecursiveAttr3:
     def __init__(self):
         self.i = 0
 
     def update(self):
-        self.i = (self.i + 1) % 10
+        self.i = (self.i + 1) % 5
 
 # Going beyond the MAX_RECURSIVE_UNION_LITERALS limit:
 reveal_type(RecursiveAttr3().i)  # revealed: Unknown | int

crates/ty_python_semantic/src/types/builder.rs

@@ -256,7 +256,7 @@ impl RecursivelyDefined {
 
 /// If the value ​​is defined recursively, widening is performed from fewer literal elements,
 /// resulting in faster convergence of the fixed-point iteration.
-const MAX_RECURSIVE_UNION_LITERALS: usize = 10;
+const MAX_RECURSIVE_UNION_LITERALS: usize = 5;
 /// If the value ​​is defined non-recursively, the fixed-point iteration will converge in one go,
 /// so in principle we can have as many literal elements as we want,
 /// but to avoid unintended huge computational loads, we limit it to 256.