Fixes #41152

Previously, when suggesting module specifiers for auto-imports, we would only look at package.json main fields if the path to the module was actually inside node_modules. This meant that if you have a monorepo that uses a node_modules symlink strategy, like yarn workspaces or lerna, everything was great, but if you just rely on tsconfig paths aliases, you could not point an alias at a package root and expect it to work:

tsconfig.json - { "paths": { "@foo": ["./foo"] } }
foo/
  package.json - { "main": "nonStandardName.js" }
  nonStandardName.ts - `export class Foo {}`
bar/
  bar.ts - `import { Foo } from "@foo"` resolves, but only relative imports are suggested

While this change seems like an improvement, I’m not convinced it’s super valuable, since the same effect could be achieved if the user had just specified the full path to the main field in their paths config, and it would be less work for the compiler and less code to maintain. I don’t know that it’s our goal for module specifier resolution to be a perfect inverse of module resolution, so there’s some room for debate over how far we should take the heuristics, especially when they involve file system reads like this one.