WIP: Update pages access control setting to public on pages deployment if access control is disabled on the instance level

What does this MR do?

#32961 (closed)

Consider the situation:

1. Access control for pages is disabled
2. The user creates a private project project_with_pages with pages, the default pages access level will be private
3. Admin enables Access control
4. Pages site becomes private

The #32961 (closed) is primary concerned with this issue on gitlab.com, and !18386 (merged) solves this by adding a migration.

But self-hosted projects can face the same issue. It actually was a conscious decision. Consider that default would be public if access control is disabled. Then:

1. User creates a private project without pages
2. Admin enabled Access Control
3. Much later user adds a pages web-site. It will be public, but user would expect it to be private.

This MR adds a hook on pages deployment which checks if Access Control is currently disabled and then makes web-site private.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• 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

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