Wrap the approvals required in a fallback rule

What does this MR do?

This allows us to treat the values from Project#approvals_before_merge and MergeRequest#approvals_before_merge the same way as other approval rules.

It also makes sure the minimum approvals required in this case, is equal than or more what was defined on a single rule in the project if there was a single rule. If there was no single rule, we use the approvals_before_merge attribute of Project

This is required to keep approvals working for users on GitLab Starter, those are only allowed to use 1 approval rule, that rule could be overridden in the merge request itself. It they want to override a project rule without selecting users, we need to correctly fall back to that.

What are the relevant issue numbers?

This should help @pslaughter in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9488/

He discovered the regression there

Does this MR meet the acceptance criteria?

• [-] Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?
• Security reports checked/validated by reviewer