[labs/analyzer] Improve module cache invalidation corner cases

https://github.com/lit/lit/pull/3333 adds the ability to return cached modules, using a cache invalidation scheme that walks the graph of any previously dereferenced models for dependencies to ensure that they are still valid, based on comparing the ts.SourceFile a given model was created with against the one in the current ts.Program.

There are a couple of cases this invalidation scheme does not cover, which may be important in plugin use cases:

• Type information cached in a module may become invalid based on a change to a different module if we haven't yet dereferenced the model for that module. Since specifically type information comes from the typechecker rather than other models, we don't need to have dereferenced the dependency model to have relied on information from it.
• Related, if an import fails to resolve and later becomes resolvable, we need to know to re-validate a model that depended on it, since the typechecker would have returned any for types it depended on from that module.

There are a few options:

• Walk the entire dependency graph when invalidating; this would eagerly create at least minimal models for all modules in the graph and is thus a performance concern, but likely the most robust.
• Keep a reverse dependency -> dependent graph when parsing a module, and upon updates to a dependency invalidate all dependents. This wouldn't catch filesystem changes unrelated from a dependency module being analyzes however, since it would only invalidate when a given dependency is re-analyzed.

Start by reading PR #3333 and the module cache invalidation implementation it introduced. Compare the two uncovered cases against the proposed graph-walking and reverse-dependency approaches, then define tests showing invalidation after an indirect type change and after a previously unresolved import becomes resolvable.