Draft: Allow container_registry_access_level to be updated by API

What does this MR do?

A new project feature called container_registry was added in !54831 (merged) (project_features.container_registry_access_level). !55327 (merged) added a background migration to copy values from projects.container_registry_enabled to project_features.container_registry_access_level. A before_update callback on Project model and a before_create callback on ProjectFeature model ensures that any changes to the Project#container_registry_enabled is copied over to ProjectFeature#container_registry_access_level. Note that the other way is not true. Changes to ProjectFeature#container_registry_access_level are not synced back to Project#container_registry_enabled.

The current situation is that all code, reads from project_features.container_registry_access_level and writes to the projects.container_registry_enabled column. And then the value is copied over to project_features.container_registry_access_level by the callbacks mentioned above.

This MR changes all writes to go to project_features.container_registry_access_level instead by:

1. Overriding the Project#container_registry_enabled= setter to write to ProjectFeature#container_registry_access_level as well. This is required because the public project create/edit API writes to Project#container_registry_enabled. At the next major version, we could drop support for the projects API to modify container_registry_enabled.
2. Adding container_registry_access_level to the list of allowed parameters in the project#update internal API, so that the container_registry_access_level can be modified via the API.
3. Allowing container_registry_access_level to be passed to the public project create and edit APIs.

It also adds container_registry_access_level to the project helper so that the frontend will be able to read its current value.

This is the 5th in a series of MRs:

1. !54831 (merged)
2. !55327 (merged)
3. !56626 (merged)
4. !55071 (merged)
5. This MR.
6. !55079 (merged)

Related to #18792 (closed)

Screenshots (strongly suggested)

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