Remove validation for ProtectedRef access levels

What does this MR do and why?

Remove validation for ProtectedRef access levels

Prior to this change CE would validate that protected tags would have exactly 1 create access level and protected branches would have exactly 1 merge access level.

This has many inconsistencies

1. This wasn't applied in EE and we allowed any number (or zero) of access levels
2. We didn't apply this to protected branch push access levels.
3. When we added Instance admins as a dropdown option we should have increased this limit to 2.

After this change we no longer validate how many access levels are assigned regardless of their type.

Logically it makes sense to select No one or Developers + Maintainers, however, selecting both has no harmful effects, developers and maintainers would be able to perform the protected action. Similarly if you do not create any access levels it behaves like No one has been selected.

I would normally lean towards ensuring at least 1 access level is defined, however, unprotect access levels behave slightly differently when zero-or-any exist and as the validator didn't exist in EE previously we should keep it this way unless we can ensure that adding a validator won't break any existing use-cases.

This change also refactors the class method for defining access levels in a ProtectedRef class. We no longer need to remove the validator so we can call super and extend with the additional scopes in EE.

Closes Branch Rules (ProtectedBranch) should not be ab... (#467378 - closed)

MR acceptance checklist

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

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

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