Refactoring Deployment Approval Rules and Summary structure for better coherency

What does this MR do and why?

This MR fixes a couple of structural problems of Deployment Approval Rules and Summary. Currently, the business logic are scattered and configurations are not aligned so it's hard for users and us to understand how the feature behaves. This MR abstracts some of the structures so that the architecture becomes coherent. Here are the key changes:

• Rule classes are modelized and located under models/protected_environments/approval_rules. All of the business logic are abstracted away to the facility. Currently, there are two types of rules, Unified Approval Rule (ex. Unified Approval Setting) and Specific Approval Rule (ex. Multiple Approval Rules).
• Deployments::ApprovalSummary is the SSOT facility to summarize approval states of a specific deployment. This is/will-be used in Public Rest API, GraphQL API and internal processing (such as Deployments::ApproveService).
• Deployment Details API exposes approval_summary as the SSOT information. It includes all of the necessary information related to the approval (including Unified Approval Rule), therefore users can only look at this field. Previously, users needed to look at multiple different fields and summarize themselves.
• Align the process flows of Unified Approval Rule and Specific Approval Rule. More specifically, fix Unified Approval Rule that is currently executing a deployment automatically. This should be decoupled from backend and implemented in frontend side. See #367943 (closed) for more information.
• Product name, documentation and internal references are all aligned. The configuration will be more intuitive that what users need to add is just a "rule".

A few notes:

• Deployment Approvals is still Beta state that is subject to change without prior notice. These minor breaking changes should be acceptable.
• It effectively resolves Consolidate permission checks for `approve_depl... (#371997 - closed).
• This addresses !96221 (comment 1101035619).
• Related to !97102 (merged) #367943 (closed)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.