Hook member roles into protected branch access levels

What does this MR do and why?

Hook member roles into protected branch access levels

This is an EE only change as member roles are an EE feature. This is the second commit in a series of changes to enable specifying custom roles as protected branch access levels e.g. allowed to merge, allowed to push, and allowed to unprotect.

This change adds a new EE module extension to the ProtectedBranchAccess concern which is included in ProtectedBranch::MergeAccessLevel, ProtectedBranch::PushAccessLevel, and ProtectedBranch::UnprotectAccessLevel.

This mimics the logic in ProtectedRefAccess concern which is additionally included into the ProtectedTag::CreateAccessLevel model.

Including humanization of the role, adding a new type, a helper method to check if the current access level is a member_role type role.

This MR also implements member_role_access_allowed? in the EE::ProtectedBranchAccess concern, along with namespace-scoping validation. This is the core access check that determines whether a user's custom role grants them permission to push, merge, or unprotect a protected branch.

The ProtectedRefAccess#check_access method dispatches to send(:\"#{type}_access_allowed?\", current_user, current_project). Adding type == :member_role will automatically route to member_role_access_allowed? defined here.

The check handles two contexts:

• Project-level protected branches — current_project is the project; check the user's member record in that project
• Group-level protected branches — current_project is still passed (it is the project being accessed), but the rule originates from the group; check that the user has the custom role inherited from the group hierarchy

A namespace validation is also added to ensure the member_role belongs to the same root namespace as the project or group.

Related to Create EE::ProtectedBranchAccess concern (type ... (#594877 - closed) Related to Implement member_role_access_allowed? and names... (#594878 - closed)