Deployment Approval service class

What does this MR do and why?

Building on !74932 (merged), this MR adds a new service (Deployments::ApprovalService) that will be used to process deployment approvals. Ci::ProcessBuildService is also updated so that we don't process builds that need approval.

Related to #343864 (closed)

How to set up and validate locally

1. Enable the deployment_approvals feature flag.

Feature.enable(:deployment_approvals)

2. Set up a project to deploy to an environment. Example job from .gitlab-ci.yml:

production:
  stage: deploy
  script:
    - echo done
  environment:
    name: production

3. Protect the environment being deployed to. See https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protecting-environments.

4. Add some required approvals to the protected environment that was just created:

ProtectedEnvironment.last.update(required_approval_count: 2)

5. Start a pipeline. The production job should be in a "blocked" state. Clicking the play button should not start the job.

6. Approve the deployment as a different user that has permission to deploy:

project = Project.find(6)
user_1 = User.find(13)
deployment = Deployment.last
service = Deployments::ApprovalService.new(project, user_1)
service.execute(deployment, :approved)

7. Verify that the production job has not been started.

8. Approve the deployment again with a different user:

user_2 = User.find(7)
service = Deployments::ApprovalService.new(project, user_2)
service.execute(deployment, :approved)

9. Verify that the production job is not blocked anymore. It should immediately become pending and get picked up by a runner shortly thereafter.

10. Repeat steps 3 to 7 with other scenarios if desired:

• When the first user rejects the deployment (service.execute(deployment, :rejected)), the job should fail.
• When the first user approves the deployment and the second user rejects it, the job should fail.
• Manual deployment jobs (when: manual) behave the same way. This will be addressed in a follow-up MR.
• The user who created the deployment cannot approve it.
• A user cannot approve the same deployment twice. We do not return an error in this scenario, but an additional approval is not created.
• A user can change their approval to a rejection (if the deployment is still waiting for more approvals).

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.