Better names of and more compatibility between ad hoc intersections of instances

[tyralla]

While working on #18433, we encountered this bug.. @ilevkivskyi identified the underlying problem, and we decided to try to reuse previously created ad hoc intersections of instances instead of always creating new ones.

While working on this PR, I realised that reusing intersections requires more complete names. Currently, module and type variable specifications are not included, which could result in mistakes when using these names as identifiers.

So, I switched to more complete names. Now, for example, <subclass of "A" and "A"> becomes <subclass of "mod1.A[builtins.int]" and "mod2.A">. Hence, I had to adjust many existing test cases where reveal_type is used.

testReuseIntersectionForRepeatedIsinstanceCalls confirms that the mentioned bug is fixed.

testIsInstanceAdHocIntersectionIncrementalNestedClass and testIsInstanceAdHocIntersectionIncrementalUnions are in a separate commit. I think they are not really necessary, so we might prefer to remove them. I added them originally because I had to adjust lookup_fully_qualified a little. The change is very simple, but I could not create a test case where it is not sufficient.

[github-actions]

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

pyodide (https://github.com/pyodide/pyodide)
- src/py/pyodide/_state.py:21: error: Incompatible types in assignment (expression has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">1", target has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">")  [assignment]
- src/py/pyodide/_state.py:21: error: Incompatible types in assignment (expression has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">2", target has type "pyodide._state.<subclass of "ModuleType" and "JsProxy">")  [assignment]

[ilevkivskyi]

Thanks!