Support CycloneDX 1.7 component version ranges

### Current Behavior

CycloneDX 1.7 introduced a notation for component version ranges, expressed in [vers](https://www.packageurl.org/docs/vers/introduction): https://cyclonedx.org/docs/1.7/json/#metadata_tools_oneOf_i0_components_items_versionRange

A common use case for ranges is to declare runtime dependencies, where an exact version is, or can't, be known upfront.

If we want to support ranges, we'll face a few challenges:

1. How do ranges contribute to component *identity*? Should they be treated like the singular version, or does a range relax what the identity even is?
2. How do ranged components interact with vulnerability analysis? What versions do we analyze, if any? Does surfacing such findings require more context for users to avoid confusion?
3. How do we deal with inputs that don't make sense, e.g. ranged components that carry hashes? Do we reject or leniently accept?
4. ...

### Proposed Behavior

Investigate the implications of adding ranged components to the platform.

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/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

Start with the CycloneDX 1.7 component versionRange specification and the platform's existing component identity and vulnerability-analysis behavior. Investigate how vers ranges affect identity, analysis, and invalid combinations such as ranged components with hashes. Document the resulting behavior and boundaries for a future implementation.

Written by the indexing model from the issue text.