…locks deferred lazy loading

When a component is placed exclusively inside a @defer block, Angular can split it into a
separate lazy chunk. That optimization silently breaks if the same component is also used as
a viewChild or contentChild predicate — the class reference in the query keeps the import
eager, so the bundler never gets a chance to defer it.

This commit introduces error NG8030 (DEFERRED_COMPONENT_USED_IN_QUERY) that fires whenever
the compiler detects this pattern during the resolve phase. The diagnostic points directly
at the predicate expression and suggests the string-based alternative with a local template
reference variable.

The check lives in the component handler's resolve phase rather than in
packages/.../typecheck/extended/checks because it needs to cross-reference two pieces of
data that only come together there: the deferred-per-block dependency map (which components
are exclusively behind @defer) and the eagerlyUsedDecls set (which components are also used
outside @defer, so they're already eager and there's nothing to warn about). The
extendedTemplateCheck interface doesn't have access to either — it only sees the template
AST and a type-check context.

The eagerlyUsedDecls guard is important: if a component appears both inside and outside a
@defer block, the import is already eager regardless of the query, so no diagnostic is
emitted.