refactor: use simpler resolve for nested optimized deps

[bluwy]

Description

When tryFsResolve tries to match id to foo > bar syntaxes, use resolvePackageData instead of the resolve dep to match paths.

We don't actually need to do a full resolve as matching with startsWith is sufficient in most case. It is even riskier doing a full resolve as the resolve algorithim in resolve can differ from Vite's resolver algorithm used to derive optimizedData.src. (Partly an issue being solved in #11410)

This PR also removes the resolve dep 🎉 It needs a tweak to postcss-import as it imports resolve too (which otherwise would've bundled resolve), but we're able to avoid that as explained in the comments.

Additional context

I'm trying to fix #11410, and figured to do this change as a stop gap as the next changes will be a bit large.

Existing tests should pass.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

Great, refactor! Good to see that ~210kb in install size disappear 🔥

[intrnl]

currently trying to create a small reproduction but I seem to be hitting this part of postcss-import which is now throwing because of the removal of resolve

https://github.com/postcss/postcss-import/blob/08dc5e76cf60ec40a81c4c12d3514a9b71088309/index.js#L318

[Bogidon]

I'm not 100% sure about this but I think there's a good chance this change might be breaking our vitest mocks of core node modules, specifically fs. Resolve has a feature for including core modules in its searches that I think resolvePackageData does not, which is what is leading this suspicion. I sadly do not have the bandwidth to create a micro reproduction, so apologies this is not more helpful.

For reproduction, you could however try running npm test off the branch linked in this PR: DataWorks-NC/quality-of-life-dashboard#119

Downgrading the version of vite to 4.2.2 should fix the issue.

[patak-dev]

@Bogidon please create a new issue with a minimal reproduction, you can link this PR there. We aren't going to properly track its resolution if not.