Replace *_access permissions with direct permission evaluation

What does this MR do and why?

Replace *_access permissions with direct permission evaluation

Move away from the transitive role-access permission model (e.g. can?(:guest_access) -> enable permissions) in ProjectPolicy toward directly evaluating permissions from a user's role via the new RolePermissions concern. This makes it explicit which permissions each role grants, rather than relying on intermediary role-access permissions that obscure which specific abilities end up allowed or denied.

Key changes:

• Include Authz::RolePermissions in ProjectPolicy with define_role_permissions(:project) to dynamically generate role_enables_ conditions for each permission
• Remove the can?(:role_access) -> enable permission rule chain and replace with direct role-based evaluation
• Move anonymous/public/internal access rules earlier and enable public_anonymous and guest permissions directly for public and internal project access
• Invert job token feature-access rules from enable-on-match to prevent-on-mismatch, simplifying the logic
• Add missing job-related permissions to developer role YAML
• Refactor Authz::Role#permissions to accept an optional scope parameter
• Update specs to reflect changed permission sets for repository and package_registry feature gating

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

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.