Use ProjectFeature class for all permission checks

What does this MR do and why?

This removes some duplicate logic from the ProjectPolicy and uses the methods in ProjectFeature, (and ProjectTeam via that). This is done as an iterative step to help clean up the logic in ProjectPolicy a little, before we implement Adapt visibility settings to new structure afte... (&8004).

There's lots more cleanup to be done so this is by no means an exhaustive MR, but meant to be a small MR to help us unravel some of the duplicated logic.

This MR:

• Uses ProjectFeature::FEATURES as the source of features in the ProjectPolicy.
  • After this is done, we end up with an extra condition package_registry_disabled, which is unused.
• Uses ProjectFeature#feature_available? as the interface for checking permissions. This reduces code leakage + duplication of logic

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.