Make the workflow for Secret Detection findings clear and adapted to their nature

Proposal

Secrets detection findings have a special behaviour: for example, if they are detected in a Merge Request, they will be "sticky" and still appear even though the last commit did not contain these secrets. For everything else, they behave like any other vulnerability, and the classic workflow can be described as (auto remediated/no longer detected is omitted on purpose, for simplicity):

graph LR
    detected[Needs triage] -->T{Triage}
    T -->|True positive| confirmed[Confirmed]
    T -->|False positive| dismissed[Dismissed]
    T -->|Remediated| resolved[Resolved]
    confirmed -->|Remediated| resolved
    resolved -->|Detected again| detected

This brings another issue specific to secrets: Once revoked, a token is harmless, and the issue is considered resolved. If the vulnerability state is set to resolved, it will be brought back to Needs triage (detected), according to the workflow above.

In the case of Secret detection, the workflow should be instead:

graph LR
    detected[Needs triage] -->T{Triage}
    T -->|True positive| confirmed[Confirmed]
    T -->|False positive| dismissed[Dismissed]
    T -->|Remediated| resolved[Resolved]
    confirmed -->|Remediated| resolved

Where a secret, once resolved, will keep this state until someone changes it manually (in the UI or via the API).