fix(ngcc): a couple of ngcc fixes - #32619

fix(ngcc): correctly read static properties for aliased classes

In ESM2015 bundles, a class with decorators may be emitted as follows:

var MyClass_1;
let MyClass = MyClass_1 = class MyClass {};
MyClass.decorators = [/* here be decorators */];

Such a class has two declarations: the publicly visible let MyClass
and the implementation class MyClass {} node. In #32539 a refactoring
took place to handle such classes more consistently, however the logic
to find static properties was mistakenly kept identical to its broken
state before the refactor, by looking for static properties on the
implementation symbol (the one for class MyClass {}) whereas the
static properties need to be obtained from the symbol corresponding with
the let MyClass declaration, as that is where the decorators
property is assigned to in the example above.

This commit fixes the behavior by looking for static properties on the
public declaration symbol. This fixes an issue where decorators were not
found for classes that do in fact have decorators, therefore preventing
the classes from being compiled for Ivy.

Fixes #31791

fix(ngcc): resolve imports in .d.ts files for UMD/CommonJS bundles

In ngcc's reflection host for UMD and CommonJS bundles, custom logic is
present to resolve import details of an identifier. However, this custom
logic is unable to resolve an import for an identifier inside of
declaration files, as such files use the regular ESM import syntax.

As a consequence of this limitation, ngtsc is unable to resolve
ModuleWithProviders imports that are declared in an external library.
In that situation, ngtsc determines the type of the actual NgModule
that is imported, by looking in the library's declaration files for the
generic type argument on ModuleWithProviders. In this process, ngtsc
resolves the import for the ModuleWithProviders identifier to verify
that it is indeed the ModuleWithProviders type from @angular/core.
So, when the UMD reflection host was in use this resolution would fail,
therefore no NgModule type could be detected.

This commit fixes the bug by using the regular import resolution logic
in addition to the custom resolution logic that is required for UMD
and CommonJS bundles.

Fixes #31791