Mark `security_scans` records as stale after 3 months

What does this MR do and why?

As the retention period of security_findings records is at most 3 months, we want to mark security_scans records older than 3 months as purged to inform the end-user that the security_findings are not available anymore for their pipeline.

We've already implemented a similar logic before but it was behind a feature flag and I didn't want to enable that feature flag as I've discovered that one of the queries would perform really badly. The problematic query was about batching over security_findings records to delete them in batches but since now we have the partitioning implemented for the security_findings table, we don't actually need to delete the security_findings as they will be dropped anyway once the related partition is detected so the only thing we need to do is mark the security_scans as purged.

High-level explanation of the changes

This MR introduces the following changes based on the aforementioned information to mark the stale security_scans records as purged:

1. Change the service layer logic to skip deleting security_findings and only mark the security_scans as purged.
2. Rename the event subscriber as it's not about deleting the security_findings anymore.
3. Rename the cronjob as it's not about deleting the security_findings anymore.
4. Some changes in different spec files to reflect the logic changes.

Relevant information

• Related to: Implement retention period for Security::Findin... (#351524 - closed)
• You can find the MR of the previous implementation here(note that we have never turned on the feature flag): Implement retention period for `security_findin... (!81423 - merged).

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.