feat(packages): PURL-based vulnerability lifecycle for packages

[Aman-Cool]

So here's the thing that's been quietly bothering me while exploring the codebase; packages have been first-class citizens in SW360 since the Siemens Healthineers contribution, but if you went to check vulnerabilities for a project that used packages instead of releases, you'd get back nothing. Not "no vulnerabilities found", just silence. The getVulnerabilitiesByProjectId call simply skipped over project.packageIds entirely and only walked releaseIdToUsage. Issue #2093 has been open on this for a while.

The fix is conceptually simple: every package already carries a PURL (e.g. pkg:npm/angular-sanitize@1.8.2). We decompose that PURL into name / namespace / version, build a synthetic Release object from those parts, and feed it straight into the existing CVE search heuristic, the same CPE-matching and fuzzy vendor/product/version search that already works for releases. No new external API, no new infrastructure, just reusing what's already there. The matched CVEs get stored as PackageVulnerabilityRelation documents in CouchDB (a parallel to the existing ReleaseVulnerabilityRelation), and two new endpoints; GET /api/packages/{id}/vulnerabilities and PATCH /api/packages/{id}/vulnerabilities; expose them over REST, following the exact same pattern as the release equivalents.

The project-level fix is in the backend service layer (VulnerabilityHandler.getVulnerabilitiesByProjectId), so every caller; not just the REST endpoint, now gets package CVEs automatically.

---

On the Thrift removal work:

This PR intentionally stays shallow with respect to Thrift. The four new service methods (getVulnerabilitiesByPackageId, addPackageVulnerabilityRelation, updatePackageVulnerabilityRelation, deletePackageVulnerabilityRelation) follow the exact same structural pattern as the existing methods sitting next to them in VulnerabilityService.thrift and VulnerabilityHandler.java. There are no new Thrift services, no new client stubs, no new inter-service wiring, it's purely additive inside an already-targeted service. When the removal work reaches VulnerabilityService, these four methods migrate identically to the rest; same effort, same pattern, nothing special to untangle. The REST layer code (PackageController, Sw360VulnerabilityService) is already pure Spring, exactly where the migration is heading anyway. This PR doesn't push Thrift deeper into the stack; if anything, the REST endpoints here are already in the post-Thrift shape.

Issue: #2093

Suggest Reviewer

@GMishx

Checklist

Must:

• All related issues are referenced in commit messages and in PR

[Aman-Cool]

@GMishx, Would love to get some eyes on this when you get a chance.
It's been sitting as an open gap for a while (#2093) and I think the approach is clean enough to land; reuses the existing CVE heuristic, follows all the same patterns as the release equivalents, and the project-level fix means every caller benefits automatically.
Happy to address any review feedback quickly. Lmk what you think!