Allow non-Any gradual return types for ambiguous overloads

[carljm]

The spec's requirement to infer Any for gradually-ambiguous overload evaluations is a regular source of discontent, as a more precise type could often still meet the graduality requirement that the inferred return type can be gradually used as if it were any of the matched-overload return types.

In fact mypy already does infer more precise types that meet this requirement. For example, mypy combines ambiguous overload returns of list[int] and list[str] into list[Any], which is gradually usable as either list[int] or list[str], and is clearly preferable to Any in its precision.

Adjust the spec language and the conformance suite tests to express the actual graduality requirements, instead of requiring exactly Any.

An inference of Any remains spec-compliant under this change, but more precise gradual types that still meet the graduality requirement can also be spec-compliant.

[carljm]

https://discuss.python.org/t/permitting-more-precise-inferred-types-from-ambiguous-overloads/108776

[jorenham]

I really like this; thanks!

[davidhalter]

Wow, if I knew it was this simple I would have done that a long time ago. I have preferred Mypy's behavior in this case and I'm happy to reintroduce it in Zuban. I originally was unhappy to remove it, because it feels much better (and I hope this improves Zuban for scipy-stubs and similar cases)...

I still feel that AnyOf might be useful, but this is great for now.

Thanks a lot!