fix(@ngtools/webpack): Validate wildcard path replacements

[jonrimmer]

As described in this angular-cli issue, the logic for handling wildcard paths in the paths plugin is broken, does not match how TypeScript works, and breaks non-relative module imports that happen to match a wildcard path.

As described in the module resolution docs, TypeScript considers each mapping in turn as a way to potentially turn a non-relative import into a relative one. However, this mapping is used if and only if the resulting path actually matches a file that exists on disk. If an import matches a path, but does not resolve to a real file, TypeScript will fall back to regular node module resolution.

For example, if I have a path mapping "*": ["./src/app"], then this will match any import, including an import of '@angular/core'. As such, TypeScript will initially try to resolve this as a file with the path {baseUrl}/./src/@angular/core. However, when it cannot find a file in this location, it will fall back to regular resolution, likely loading the module from {baseUrl}/node_modules/@angular/core.

As it stands, the paths plugin does not validate whether the mapped file exists. It assumes it does and passes it on to Webpack without checking. The result is that basic wildcard mappings, of the type given in the TypeScript documentation, break things, because they cause the plugin to transform non-relative module imports into invalid, relative mappings.

This change attempts to fix the problem by validating whether the result of applying a mapping matches a real file. It considers two possibilities:

1. The mapped path exactly matches a file on disk. E.g. an import of style/something.css, where there is a file {baseUrl}/src/app/style/something.css.
2. The mapped path is an extensionless import that TypeScript can resolve. E.g. an import of core/utils, where there is a file {baseUrl}/src/app/core/utils.ts (or .tsx, etc.).

Even with this change, things probably still don't fully match how TypeScript handles path mappings, but it should be considerably closer.

[jonrimmer]

Ugh, this has some issues with linting and matching the guidelines. I'm going to close it and try again.