[ty] don't assume that deferred type inference means deferred name resolution (#20160)

## Summary

We have the ability to defer type inference of some parts of
definitions, so as to allow us to create a type that may need to be
recursively referenced in those other parts of the definition.

We also have the ability to do type inference in a context where all
name resolution should be deferred (that is, names should be looked up
from all-reachable-definitions rather than from the location of use.)
This is used for all annotations in stubs, or if `from __future__ import
annotations` is active.

Previous to this PR, these two concepts were linked: deferred-inference
always implied deferred-name-resolution, though we also supported
deferred-name-resolution without deferred-inference, via
`DeferredExpressionState`.

For the upcoming `typing.TypeAlias` support, I will defer inference of
the entire RHS of the alias (so as to support cycles), but that doesn't
imply deferred name resolution; at runtime, the RHS of a name annotated
as `typing.TypeAlias` is executed eagerly.

So this PR fully de-couples the two concepts, instead explicitly setting
the `DeferredExpressionState` in those cases where we should defer name
resolution.

It also fixes a long-standing related bug, where we were deferring name
resolution of all names in class bases, if any of the class bases
contained a stringified annotation.

## Test Plan

Added test that failed before this PR.

crates/ty_python_semantic/resources/mdtest/classes.md

@@ -0,0 +1,25 @@
+# Class definitions
+
+## Deferred resolution of bases
+
+### Only the stringified name is deferred
+
+If a class base contains a stringified name, only that name is deferred. Other names are resolved
+normally.
+
+```toml
+[environment]
+python-version = "3.12"
+```
+
+```py
+A = int
+
+class G[T]: ...
+class C(A, G["B"]): ...
+
+A = str
+B = bytes
+
+reveal_type(C.__mro__)  # revealed: tuple[<class 'C'>, <class 'int'>, <class 'G[bytes]'>, typing.Generic, <class 'object'>]
+```