Consider deferring module top level in type checker

[ilevkivskyi]

We currently never defer module top levels in type checker. This can cause some Cannot determine type of x errors in import cycles. They are real in some sense, because such code would almost certainly fail at runtime. However, this might sometimes be useful in stubs (as practice shows, this is however not important and shows up only in highly entangled import cycles, such as e.g. builtins SCC).

[ilevkivskyi]

See #6312 for an example when the error happens.

[russelldavis]

They are real in some sense, because such code would almost certainly fail at runtime.

I think it's import to distinguish the ones that would fail at runtime from the ones that would not. I think there are a lot of common cases that do not fail at runtime that are worth supporting.

[ilevkivskyi]

With some more experience, it looks like this can cause troubles.

More generally, the deferral in type checker is different from both semantic analyzer and the daemon: the first two defer either module top level or top-level function and defer until fixed point (our large cut-off), while type checker never defers module top levels, and defers innermost functions, and have hard-coded small number of deferrals.