Analysis decisions in multiple project versions

### Current Behavior

E.g. 10 versions of the same project exist in Dependency-Track. A vulnerability is found in a component which is contained in 9 of these.
Now, somebody needs to go through all versions and do the analysis decision/possibly suppression in each version separately.

Addition:
If the vulnerability was suppressed, because it has no relevance for this project, and a 11th project version is added, you need to suppress it again (and for each later version again.)

### Proposed Behavior

When doing analysis decisions, a checkbox should be available "Apply to all versions of this project, now and in future".
If selected, the same should be applied to all currently existing project versions of the same project, and any newly added version, or later uploaded bom in any version of the same project, the same decision should be taken over.
Minimum Requirement would be rolling it out to all KNOWN project versions. The future versions would be nice but if technically difficult not a deal breaker for me. Could also make sense to have both options separate, if someone only wants to apply it to current known versions but not to future versions automatically.

### Considerations to make
1. A vulnerability can apply to multiple versions of the same project, but different component versions. Differences in PURLs (e.g. with vcs suffix) might also be a topic here.
Proposal: Treat all versions and variants of the 3rd party component identically, possibly show the user a list of project versions together with affected component versions in them which he needs to confirm, to make him aware of this. In the typical use case you confirm how a component was used and can, no matter which previous version was used, store the assessment for all versions.
2. A vulnerability can apply to multiple versions of the same project, but in entirely different 3rd party components
Proposal: Rare use case in my opinion. Either use the proposal from 1) and include also other components affected, or limit it strictly to the same component name/identifier (without versions etc).
3. A vulnerability could apply to multiple different project parts, maintained as different projects in Dependency-Track (e.g. different services).
Proposal: In first go, ignore this use case to get the base feature for the main use case done faster. Potential later addon could be a UI which allows selecting other projects the user has access to, which are also affected by this component, and allows rolling out the decision to other project parts.

See also:
1. https://app.slack.com/client/T04T40NHX/C6R3R32H4/thread/C6R3R32H4-1668779395.683739
2. Related but not the same, but contains some discussions about this here: https://github.com/DependencyTrack/hyades/issues/930

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