Move Vulnerabilities API to Vulnerability Findings API

What does this MR do?

Background

During the review of Create a Vulnerability from Finding (API call for the backstage implementation of the First-class Vulnerabilities MVC), the maintainer had raised a hand about the inconsistency in the /projects/:id/vulnerabilities endpoint behavior. This API path currently returns different types of objects depending on the first_class_vulnerabilities feature flag state: Vulnerability instances in case first_class_vulnerabilities is enabled and Vulnerabilities::Occurrence instances otherwise.

first_class_vulnerabilities feature flag controls the availability of the upcoming MVC Standalone Vulnerability objects (aka First-class Vulnerabilities) functionality.

There was a decision to reserve the /projects/:id/vulnerabilities for serving the Vulnerability instances only regardless of the first_class_vulnerabilities feature flag state. The current implementation of it is moved to /projects/:id/vulnerability_findings API path. Initially, this change was planned to be covered with a feature flag and released together with #13561 (closed). This decision makes this change immediate breaking change for the current Vulnerabilities API consumers.

To be noted:

• current Vulnerabilities API is in the Alpha stage and the warning about possible breaking changes is explicit
• this API is used by GitLab frontend, the corresponding changes were made to switch the API path used

This MR

Here are the changes that move the Vulnerabilities API to become Vulnerability Findings API. The term Finding is the new name for Occurrence. More on terminology here.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• [-] Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team