Do not narrow types to Never with binder

[ilevkivskyi]

Fixes#18967
Fixes#16494
Fixes#15793
Fixes#12949

As you can see from updated test cases, it is kind of gray area, so whether we go this way will depend on the mypy_primer results (and also potentially on Dropbox internal code bases, where the above issue may cause problems).

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

pandas (https://github.com/pandas-dev/pandas)
- pandas/io/formats/style.py:1903: error: "Never" has no attribute "shape" [attr-defined]- pandas/io/formats/style.py:1906: error: "Never" has no attribute "shape" [attr-defined]
streamlit (https://github.com/streamlit/streamlit)
+ lib/streamlit/dataframe_util.py: note: In function "convert_anything_to_list":+ lib/streamlit/dataframe_util.py:927:17: error: List item 0 has incompatible type "Union[str, int, float]"; expected "V_co" [list-item]
static-frame (https://github.com/static-frame/static-frame)
- static_frame/core/frame.py:5610: error: Unused "type: ignore" comment [unused-ignore]
spark (https://github.com/apache/spark)
+ python/pyspark/core/context.py:837: error: Unused "type: ignore" comment [unused-ignore]+ python/pyspark/core/context.py:838: error: Unused "type: ignore" comment [unused-ignore]+ python/pyspark/ml/connect/readwrite.py:98: error: Redundant cast to "JavaEstimator[Any]" [redundant-cast]+ python/pyspark/ml/connect/readwrite.py:101: error: Redundant cast to "JavaEvaluator" [redundant-cast]
Tanjun (https://github.com/FasterSpeeding/Tanjun)
- tanjun/parsing.py:588: error: "Never" has no attribute "__iter__" (not iterable) [attr-defined]- tanjun/dependencies/limiters.py:851: error: "Never" has no attribute "unlock" [attr-defined]

[sterliakov]

This impacts several existing issues: sterliakov/mypy-issues#27

[ilevkivskyi]

Hm, interesting... As I said, it is gray area, but IMO most of the impact looks positive, I will however take a closer look later today or tomorrow.

[ilevkivskyi]

OK, I went through mypy_primer and the mypy-issues, overall I found ~dozen cases where this PR either completely fixes an issue or improves it, and only a single case where it makes things (slightly) worse. Which kind of makes sense, in tricky situations people usually expect mypy to trust the most recent type information available.

@JukkaL unless you have objections, I am going to merge this soon.

[JukkaL]

I agree that the new behavior seems better.