Update symlink cache from AutoImportProvider resolution even if host project already contains the file via its realpath

[andrewbranch]

This fixes part of a bug I noticed while writing #46569, mentioned in the test comment there. An AutoImportProviderProject contains only files that the host Project does not. However, it’s possible, as in the test written here, that the main project only knows about a file via its realpath, but it also exists as a symlink inside node_modules. Because that symlink was mentioned in the package.json dependencies, we discover it as part of spinning up an AutoImportProviderProject. However, when we see that the SourceFile we resolved to is already contained by the host Project, we skip it entirely, discarding the knowledge of the symlink we found. This PR allows the AutoImportProviderProject to add that symlink knowledge to the host project’s cache before it decides not to add the file to itself. This way, the host Project is still responsible for generating auto-imports of that SourceFile, but it can come up with the correct module specifier for it using the symlink information discovered by the AutoImportProviderProject.

[andrewbranch]

The other part of the bug is this—for this test to work, this package.json needs "types": "index" exactly—leaving it off or specifying any file extension breaks the resolution attempted by the AutoImportProviderProject. My attempt to leverage resolveTypeReferenceDirective for this has hit its limit; there probably needs to be a much more permissive module resolution function written specifically for this. I’ll follow up with a separate PR for that.

[amcasey]

Your explanation makes sense and your code change looks consistent with your explanation.