Yarn2 simplifications

[fviernau]

This PR is only a starter for a series of PRs to make the code simpler and easier to read.

This are preparations which occurred when trying to re-use the parsePackage() and parseProject() functions used for the other three node managers, but further preparations will be needed..

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.94%. Comparing base (eeba28e) to head (0b4edd7).
Report is 7 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #9486      +/-   ##
============================================
+ Coverage     67.93%   67.94%   +0.01%     
- Complexity     1289     1290       +1     
============================================
  Files           249      249              
  Lines          8794     8798       +4     
  Branches        913      912       -1     
============================================
+ Hits           5974     5978       +4     
  Misses         2434     2434              
  Partials        386      386              

Flag	Coverage Δ
funTest-docker	64.89% <100.00%> (+0.07%)	⬆️
funTest-non-docker	33.33% <ø> (ø)
test	35.74% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[sschuberth]

Nit: Maybe put before moduleId to maintain alphabetical sorting of extension functions?

[sschuberth]

Commit message: It's a bit odd to refer to an upcoming change that's not part of this PR. Also, just from looking at the diff it's not clear why details. can just be omitted, i.e. why details.version and version seem to refer to the same value.

Actually, as version is defined as

val version = header.version.cleanVersionString()

and used as

val details = packagesDetails["${header.rawName}@$version"]

I'd argue that version should only be used to create the key for the lookup in packagesDetails, and otherwise details.version should exclusively be used as the package version.

[fviernau]

I believe the change makes sense and is a valid simplification, because of this:

1. details is a PackageJson instance and it is requested with the moduleId which uses the cleaned version obtained from cleanVersionString() (view yarn npm view).
2. The PackageJson.version returned by that yarn npm view always is identical with the version requirested,
   which implies the details.version and version always is identical.

[sschuberth]

2. The PackageJson.version returned by that yarn npm view always is identical with the version requirested

Would you have a(n API) reference for that?

Anyway, would it make sense to postpone this commit to the PR that actually benefits from it? Right now I just don't see why replacing details.version with version is an improvement besides a few characters saved. To me, this is semantically mixing up "the version used for requesting details" with "the version returned as part of details" even if they may be the same.

[fviernau]

Ok, I've dropped it.