gh-159092: Optimize comparisons in list operations

[hetaozdh]

List scans (in, index, count, remove, and element comparisons in list.__eq__()) call PyObject_RichCompareBool(). For exact builtin type such as int, float or str pairs, we can avoid the generic rich-comparison dispatch and use a specialized comparison instead, following the approach already used by list.sort().

Benchmarks

Microbenchmarks (ns/element, 20000-element list, match near the end, --disable-gil build):

Operation	Main	PR	Speedup
x in list[int]	9.14	3.24	2.82×
list.index(x)	9.45	3.66	2.58×
list.count(x)	9.71	3.38	2.87×
x in list[str]	8.83	4.79	1.84×
list.remove(x)	8.30	2.44	3.40×
[int] == [int]	9.24	3.63	2.55×
[str] == [str]	10.64	8.81	1.21×

Selected pyperformance benchmarks:

• bm_hexiom: ~1.10× faster.
• bm_meteor_contest, bm_go, bm_deltablue, bm_comprehensions: no significant difference.

I will try the full benchmarks when I am free.

Correctness

The fast path preserves the identity shortcut of PyObject_RichCompareBool(), including NaN identity semantics. Other type combinations retain the existing comparison path, preserving rich-comparison dispatch and recursive-comparison protection.

Tested with test_list, test_sort, test_operator and test_compare, plus differential checks covering subclasses, NaNs, custom __eq__ implementations, large integers, string representations and mutation during comparison. The existing test_deopt_from_append_list environment failure also occurs on unmodified main.

• Issue: Inline the per-item equality check in list.__contains__/index/count/remove #159092