Refactor: custom user can see project security dashboard

What does this MR do and why?

• There is already a fix in place for #421528 (closed) via !129742 (merged)
• This is a refactor that ensures we proactively prevent this ability if security_and_compliance_disabled is on for a project. Now, we don't need to worry about always checking ~security_and_access_disabled before enabling access_security_and_compliance because it is prevented and with our policy framework (Declarative Policy), one prevention is all that is needed to block the ability.
• Having these checks be flatter is more efficient for Declarative Policy: https://gitlab.com/gitlab-org/ruby/gems/declarative-policy/-/blob/main/doc/optimization.md?ref_type=heads#flat-is-better-than-nested

Screenshots or screen recordings

Abilities Before vs After this MR

Before

> ProjectPolicy.ability_map.map.select { |k,v| k == :access_security_and_compliance }
=> {:access_security_and_compliance=>
  [[:enable, #<Rule all?(~security_and_compliance_disabled, can?(:developer_access))>],
   [:enable, #<Rule all?(~security_and_compliance_disabled, auditor)>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_vulnerability)>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_dependency, dependency_scanning_enabled)>]]}

ProjectPolicy.ability_map.map.select { |k,v| k == :admin_vulnerability }
=> {:admin_vulnerability=>
  [[:prevent, #<Rule archived>],
   [:enable, #<Rule all?(can?(:read_security_resource), ~security_and_compliance_disabled, can?(:developer_access))>],
   [:prevent, #<Rule all?(auditor, ~developer)>],
   [:prevent, #<Rule read_only>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_admin_vulnerability)>]]}

ProjectPolicy.ability_map.map.select { |k,v| k == :read_vulnerability }
=> {:read_vulnerability=>
  [[:enable, #<Rule all?(can?(:read_security_resource), ~security_and_compliance_disabled)>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_vulnerability)>]]}

After

ProjectPolicy.ability_map.map.select { |k,v| k == :access_security_and_compliance }
=> {:access_security_and_compliance=>
  [[:prevent, #<Rule security_and_compliance_disabled>],
   [:enable, #<Rule can?(:developer_access)>],
   [:enable, #<Rule auditor>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_vulnerability)>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_dependency, dependency_scanning_enabled)>]]}

ProjectPolicy.ability_map.map.select { |k,v| k == :admin_vulnerability }
=> {:admin_vulnerability=>
  [[:prevent, #<Rule archived>],
   [:enable, #<Rule all?(can?(:read_security_resource), can?(:developer_access))>],
   [:prevent, #<Rule security_and_compliance_disabled>],
   [:prevent, #<Rule all?(auditor, ~developer)>],
   [:prevent, #<Rule read_only>],
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_admin_vulnerability)>]]}

ProjectPolicy.ability_map.map.select { |k,v| k == :read_vulnerability }
=> {:read_vulnerability=>
  [[:enable, #<Rule can?(:read_security_resource)>],
   [:prevent, #<Rule security_and_compliance_disabled>], 
   [:enable, #<Rule all?(custom_roles_allowed, role_enables_read_vulnerability)>]]}

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.