Change default `only` policy to enable Pipelines for merge requests by default

What does this MR do?

We want to dogfood Pipelines for merge requests ourselves. This feature will run pipelines on merge ref before the actual merge happens, thus developers will notice potential master:broken changes before it interferes the entire development cycle.

This MR is yet another crazy idea to enable this feature in GitLab CE/EE development cycle. The outline is

• We change the default only policy to only: { refs: %w[protected_refs tags merge_requests] }.
• We put this change behind the feature flag ci_new_default_only and make this disable by default.

This way, we don't need to refactor entire .gitlab-ci.yml, as merge request pipelines are enabled by default. We still have to fix a few edge cases, but it's very minimal as you can see in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27264.

Please note that this new only behavior is also along with our future vision. We will eventually turn down aim-less branch pipelines for merge requests.

Related: https://gitlab.com/gitlab-org/gitlab-ce/issues/57190

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

Performance 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