Address analysers generating inconsistent vulnerability identifiers
We observed during a [spike issue discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/423557#note_1541778476) for the [vulnerability grouping feature](https://gitlab.com/groups/gitlab-org/-/epics/10164) development that [analysers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html) are generating inconsistent identifier mappings deviating from the [documented identifier format](https://docs.gitlab.com/ee/development/integrations/secure.html#identifiers) and this inconsistency hinders feature development on top of the data present in `vulnerability_identifiers` table.
Known scenarios where the inconsistency causes problem:
1) [OWASP top 10 vulnerability grouping](https://gitlab.com/gitlab-org/gitlab/-/issues/267588/designs/design_1692329456491.png) feature as part of https://gitlab.com/groups/gitlab-org/-/epics/10164+
2) [Identifier filtering](https://gitlab.com/gitlab-org/gitlab/-/issues/342079/designs/design_1697002732598.png) as part of https://gitlab.com/groups/gitlab-org/-/epics/3429+.
Anticipated scenarios in future where this can cause problem:
3) https://gitlab.com/groups/gitlab-org/-/epics/3429+
For more details: see discussion - https://gitlab.com/gitlab-org/gitlab/-/issues/423557#note_1541778476
### High-Level Implementation Plan
(This focused on OWASP identifiers but priority should be considered for all types)
- ~backend Audit existing analyzers to ensure they are generating correctly formed OWASP identifiers[^1]
- ~backend Create background migration for normalizing existing data (`where(external_id: ["A8"]).update(external_id: "A8:2017)`)
- ~backend Add strict validation to [common identifier types](https://gitlab.com/gitlab-org/security-products/analyzers/report/-/blob/5fd35d3e9e1552d92bce526d5e92c3e7ea765ed7/identifier.go#L12-35) via schema (breaking change) and report module for generating common identifiers
[^1]: Some work will be needed to ensure `A8` is mapped to the correct year (or default to latest which is easy but could lead to inconsistencies) but we might be able to assume non-padded entries are 2017 vs 2021 or the up-and-coming 2024
issue