Define vulnerability database schema

### Current Behavior

We're aiming to build a mechanism to assemble and distribute a vulnerability database tailored to Dependency-Track's needs.

The goals for our own database are defined here: https://docs.google.com/document/d/1DVV4ik7NGOBc6u-fdPlPVKoplNmSpzDT6iC4FJAFYi0/edit?tab=t.0#heading=h.w22q0gsagz1c

To enable implementation work on this effort, we need a schema that defines how we persist the data in question.

### Proposed Behavior

Define a database schema for the vulnerability database itself.

> [!NOTE]
> A SQL schema (e.g. for SQLite) is preferred, but we are open to other solutions.

Quoting some relevant entries of [our goals](https://docs.google.com/document/d/1DVV4ik7NGOBc6u-fdPlPVKoplNmSpzDT6iC4FJAFYi0/edit?tab=t.0#heading=h.w22q0gsagz1c):

* The database MAY leverage existing schemata for vulnerability data, such as [CycloneDX](https://cyclonedx.org/capabilities/bov/),
[CVE 5.x](https://github.com/CVEProject/cve-schema), and [OSV](https://ossf.github.io/osv-schema/).
* The database MUST combine data from multiple public sources, such as NVD, GitHub Advisories, and OSV.
* The database MUST support addition of more data sources over time, such as Red Hat’s.
* The database SHOULD support regional databases, such as China’s CNNVD. Since not all users will need or even want those, the database SHOULD provide a means to exclude them.
* The database MUST support software and hardware components.
* The database MUST support component identifiers in CPE and [Package URL](https://tc54.org/purl/) format. * The database SHOULD be designed in a way that allows for more identifiers to be added later, for example [GS1 GTIN](https://www.gs1.org/standards/id-keys/gtin).
* The database SHOULD represent versions and version ranges in [vers](https://tc54.org/vers/) format.
* The database MAY support additional matching information, such as imports and symbols for reachability analysis. [Go’s database](https://go.dev/doc/security/vuln/database) provides this data. [Cdxgen](https://cyclonedx.github.io/cdxgen/#/ADVANCED?id=reachability-based-call-stack-evidence) can produce call stack information in BOMs.
* The database SHOULD be file-based. Distributing static files via CDN is preferable to operating a publicly available service, both from a cost and availability perspective.
* The database SHOULD provide a mechanism to consume only a subset of data. Consumers should not have to re-download 10s of gigabytes of files, when most of it hasn’t changed.
* The database MAY provide a mechanism to consume it as a stream, or in chunks. New deployments of DT would be operational quicker, if the latest vulnerabilities could be consumed first, in a short period of time.
* The database SHOULD provide a means for maintainers and community members to fix erroneous data. For example, wrong version ranges, or missing severities.
* The database MAY support enrichment of vulnerability data with volatile information, such as [EPSS](https://www.first.org/epss/) scores, or presence in [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog).
* The database MAY leverage existing schemata for vulnerability data, such as [CycloneDX](https://cyclonedx.org/capabilities/bov/),
[CVE 5.x](https://github.com/CVEProject/cve-schema), and [OSV](https://ossf.github.io/osv-schema/).

The schema should focus on data we actually *need*, not on what data is available.

> [!NOTE]
> The vulnerability database’s schema does not necessarily have to align with DT’s database schema.
> However, it would be beneficial if it was easy to consume from. Since we want this to be file-based, we can't rely on some web API to transform and filter data.

### 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