Include associated source packages in vulnerability analysis for OS distro packages in SBOMs (e.g. Debian)

### Current Behavior

SBOMs for containers often contain components based on installed binary packages from the distribution package repository. This makes sense because that’s what’s actually installed and present in the image. However, in many cases vulnerabilities are reported against the source packages instead, which don’t always share the same name as the binary packages (e.g. in [Debian](https://packages.debian.org/bookworm/gnupg), binary package `gnupg` is built from source package `gnupg2`). We don’t necessarily want to include the source packages in the SBOM because they aren’t present in the image, but we do want them analysed for vulnerabilities that are present in the binaries built from them.

Today Dependency Track isn’t aware of this source package -> binary package relationship, and there doesn’t appear to be a standard way to represent that in a CycloneDX SBOM (please correct me if I’m wrong). This can result in false negatives (for example `DEBIAN-CVE-2025-68972` in OSV, which lists `pkg:deb/debian/gnupg2?arch=source&distro=debian-12` as an affected component but does not match on `gnupg`).

(Related [Slack thread](https://owasp.slack.com/archives/C6R3R32H4/p1778601464686649))

### Proposed Behavior

Syft and Grype handle this by appending an additional non-standard parameter to the PURL called `upstream` which specifies the name of the source package (i.e. `pkg:deb/debian/gnupg-utils@2.2.40-1.1%2Bdeb12u2?arch=amd64&distro=debian-12&upstream=gnupg2`). Grype understands this parameter and can then use it to query its database and properly attribute vulnerabilities to the binary package(s).

For Syft-generated PURLs which include this `upstream` information I would like Dependency Track to include the source package in its vulnerability analysis, and match vulnerabilities in the source package against the binary package component.

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested