dotnet-deps-binary-cataloger selects package versions that are written over by the runtime

**What happened**:
Generated a sbom for an application that references an old dotnet standard package that is written over by the runtime. But the sbom contained the package reference version and not the runtime version which is actually contained in the output folder. This can cause false positive/negatives and is detrimental to sbom quality/actionability.

**What you expected to happen**:
If I build in a certain dotnet version including a package reference with a version that is lower than what is listed under the runtime dependencies dotnet will resolve the dependency from the sdk version.

These packages are still referenced for dotnet standard compatability, but are these days included in the sdk/runtime and will be written over by them when building.
They're listed [here ](https://github.com/dotnet/runtime/tree/main/src/libraries.) for the runtime's master but you should reference the tag for the version you build with.
Blazor WASM for example extends these because they also need certain wasm packages.

Microsoft themselves at one point maintained a [list with some of these for aspnet](https://github.com/dotnet/runtime/blob/release/9.0/src/installer/pkg/sfx/Microsoft.NETCore.App/PackageOverrides.txt), but its not complete and its [applied here](https://github.com/dotnet/sdk/blob/7deb36232b9c0ccd5084fced1df07920c10a5b72/src/Tasks/Microsoft.NET.Build.Tasks/ResolveTargetingPackAssets.cs#L199).
In their own component detector (their equivelent of our cataloger) they [used](https://github.com/microsoft/component-detection/pull/1285/files#diff-2321c5fc013837e238b374f1c086a92703d4a7592a388d0f4038e0186595e51a) such lists to exclude these entries.

You could do the same by writing an app that dynamicly builds these projects with plausable projects to generate such a list, which is not unlike what they have done. But this seems unfruitfull and needlessly complex as they themselves missed Systems.Numeric.Vector for example.
It's far easier to compare the deps.json runtime section with the package entries in the same file.
The version of the package would then be set to the version you built with to accurately reflect the resolved version.

I think its worth considering if these should be included to begin with as they often do not exist on NuGet and vulnerabilities in these cases are listed under cve's that adress the sdk. Maybe this deserves a seperate issue.

(same section)

And under the packages:

The DLL in ILSPY

**Steps to reproduce the issue**:
syft scan the outputfolder of a dotnet project which references for example System.Security.Cng:5.0.0 or any of the packages that are now included in the runtime/sdk

**Environment**:
- Output of `syft version`: 1.31.0
- OS (e.g: `cat /etc/os-release` or similar): win-x64

Start with the dotnet-deps-binary-cataloger and reproduce the issue by scanning a .NET output folder containing an older System.Security.Cng package. Compare the package entries with the deps.json runtime section and verify that generated SBOM versions reflect the runtime-resolved versions. Done means overwritten runtime packages no longer retain misleading package-reference versions.

Written by the indexing model from the issue text.