CSP De-Designation Cleanup of framework settings

What does this MR do and why?

When a CSP Group is de-designated, we need to clean up project settings.

How to set up and validate locally

Ensure you have a local setup with an ultimate license, and at least two top level groups.

Setup Group with CSP flag.

1. Enable the feature flags:

   Feature.enable(:security_policies_csp)
   Feature.enable(:include_csp_frameworks)

2. Create a top-level group and assign it as a CSP: http://gitlab.localdev:3000/admin/application_settings/security_and_compliance#js-centralized_security_policy_management_setting
3. Now navigate to your CSP Group(example for gitlab-org/gitlab-test) to the Compliance Frameworks page and create a new framework. Making sure to at least supply a name, description and color.
4. Now navigate to a non-CSP Group that would have that framework inherited, making sure that you have at least one project created. Go to projects, e.g. http://gitlab.localdev:3000/groups/twitter/-/security/compliance_dashboard/projects, and assign the CSP compliance framework to the a project.
5. Now Navigate back to CSP designation, and un-assign or assign a different group as CSP.
6. A background job will run, ComplianceManagement::ProjectSettingsDestroyWorker, which will clean up the project settings.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #557587 (closed)