Offer alias-based de-duplication of vulnerabilities

### Current Behavior:

#1642 introduced tracking of vulnerability aliases. We now know which vulnerabilities describe the same issue, but we don't yet use this data to reduce the overall noise of findings. Clients may perform de-duplication based on their specific needs (e.g., always preferring GHSA over CVE), but we should offer a canonical solution from the server-side.

### Proposed Behavior:

There should be a mechanism to de-duplicate vulnerabilities. In order to stay backwards-compatible, new API endpoints or opt-in parameters should be introduced.

Note that the intention is **not** to de-duplicate during vulnerability data ingestion! We still want to keep the data from all sources.

There are multiple constraints that need to be considered. Steve mentioned a few of them in https://github.com/DependencyTrack/dependency-track/pull/1912#issuecomment-1228505074:

> * The most desired approach would be to favor CVE's over any of the alternative identifiers. This assumption should not be hard-coded.
> * There will be occasions where a CVE does not exist, yet there are aliases between say GHSA and OSSINDEX. Need to figure out how to handle this case.
> * There will be occasions where a CVE does not exist initially, but a OSSINDEX finding does. That OSSINDEX finding could be audited. At a later time, a CVE may be created and now there's a mapping. This happened with log4j and is likely the norm for high-profile vulnerabilities. I don't think we want to de-dup any finding that has an existing audit.

(There will be more constraints than this)