Consolidate FOSS and EE ProtectedBranch JS files

What does this MR do?

This MR is a first effort to consolidate both EE and FOSS Protected Branches features. It's related to this issue but it's been developed so that we can move forward with the integration of Deploy Keys in Protected Branches.

As it focuses on JS files, this MR mainly brings the following EE files into CE:

• ee/app/assets/javascripts/projects/settings/constants.js -> app/assets/javascripts/projects/settings/constants.js
• ee/app/assets/javascripts/protected_branches/constants.js -> app/assets/javascripts/protected_branches/constants.js
• ee/app/assets/javascripts/projects/settings/access_dropdown.js -> app/assets/javascripts/projects/settings/access_dropdown.js
• ee/app/assets/javascripts/protected_branches/protected_branch_create.js -> app/assets/javascripts/protected_branches/protected_branch_create.js
• ee/app/assets/javascripts/protected_branches/protected_branch_edit.js -> app/assets/javascripts/protected_branches/protected_branch_edit.js

This refactoring also introduces the hasLicense check, mostly used in the AccessDropdown class. As long as we have not fully consolidated CE and EE, we need to keep the current behaviour (ie. users should only show up in the EE version of protected branches dropdowns - more here about this EE-only feature). Once CE/EE consolidation is (close to) complete, hasLicense will be removed in all relevant files.

Once this MR goes out, it'll be easier to work on the frontend part of the Deploy Keys integration into Protected Branches: !35638 (merged)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Related to #30769 (closed)