Add 'resolved' state and resolution tracking to Vulnerabilities

What does this MR do?

This MR is a follow-up after adding the ability for users to resolve Vulnerabilities. It resolves this issue.

See the terminology being Vulnerabilities and Findings here.

Basically, Findings (formerly named Occurrences) represent the concrete instances of vulnerable application code that have been detected in the default branch of the project (e.g. master) and therefore stored into the database to display them in Project Security Dashboard.

Findings are ephemeral, they come and go with every new commit merged to the default branch. Vulnerabilities are persistent Issue-like objects that support the AppSec's team interaction with detected vulnerability. It could be discussion, marking as false-positive (dismissal), marking as resolved, etc.

The entire feature is called Standalone Vulnerability Objects. The backstage backend work for it is being done within #10242 (closed).

Initially, the Vulnerability object was introduced as having open and closed states similarly to other Issuables. However, some potential drawbacks of this approach were pointed out. Also, from the UX perspective, Vulnerability was re-iterated to have open/resolved/closed state model thus making it different from other Issuables.

Updates to the Vulnerability model in this MR:

• Vulnerabilities receive a new resolved state, all API and service layer code that deals with the resolution of the Vulnerabilities is updated to support that
• Findings will have their resolved state based exclusively on the parent Vulnerability resolved status
• Findings will have their dismissed state based on dismissal Feedback presence or belonging to a closed Vulnerability

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry | No changelog as this feature is hidden behind a feature flag
• [-] Documentation created/updated or follow-up review issue created | Documentation is going to be added in form of stubs, which are going to be actualized later, when the feature flag is removed.
• 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