[red-knot] handle cycles in MRO/bases resolution (#16693)

There can be semi-cyclic inheritance patterns (e.g. recursive generics)
that are not technically inheritance cycles, but that can cause us to
hit Salsa query cycles in evaluating a type's MRO. Add fixed-point
handling to these MRO-related queries so we don't panic on these cycles.

The details of what queries we hit in what order in this case will
change as we implement support for generics, but ultimately we will
probably need cycle handling for all queries that can re-enter type
inference, otherwise we are susceptible to small changes in query
execution order causing panics.

Fixes #14333
Further reduces the panicking set of seeds in #14737

crates/red_knot_python_semantic/resources/mdtest/generics/classes.md

@@ -162,6 +162,8 @@ class Sub(Base[Sub]): ...
 reveal_type(Sub)  # revealed: Literal[Sub]
 ```
 
+A similar case can work in a non-stub file, if forward references are stringified:
+
 `string_annotation.py`:
 
 ```py
@@ -174,6 +176,8 @@ class Sub(Base["Sub"]): ...
 reveal_type(Sub)  # revealed: Literal[Sub]
 ```
 
+In a non-stub file, without stringified forward references, this raises a `NameError`:
+
 `bare_annotation.py`:
 
 ```py
@@ -184,5 +188,13 @@ class Base[T]: ...
 class Sub(Base[Sub]): ...
 ```
 
+## Another cyclic case
+
+```pyi
+# TODO no error (generics)
+# error: [invalid-base]
+class Derived[T](list[Derived[T]]): ...
+```
+
 [crtp]: https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
 [f-bound]: https://en.wikipedia.org/wiki/Bounded_quantification#F-bounded_quantification