This commit reverts the previously introduced concurrent pipeline
schedule creation which was a viable solution for mitigating
inconsistent pipeline schedule by Sidekiq Memory Killer.

Fixing the bug

Currently, pipeline schedule worker is unstable because it's
sometimes killed by excessive memory consumption.
In order to improve the performance, we add the following fixes:

1. next_run_at is always real_next_run, which means the value
   always takes into account of worker's cron schedule
1. Remove exlusive lock. This is already covered by real_next_run
   change.
1. Use RunPipelineScheduleWorker for avoiding memory killer.
   Memory consumption is spread to the multiple sidekiq worker.

Currently, schedule head pipeline update method which executed after
pipeline creation does not take into account of merge reqeust
pipelines. We should use dedicated `all_merge_requests` method
in this case.

- Adds an endpoint on PipelinesController
- Adds a service that iterates over every build in a stage and
plays it.
- Includes 'play_manual' details on EntitySerializer
- Builds a new Stage state: PlayManual. An stage can take this status if
it has manual builds or an skipped, scheduled or manual status
- Includes FE modifications and specs

Due to the nature of pipelines for merge requests, deployments.ref can
be a merge request ref instead of a branch name.

We support the environment auto-stop hook for this case

If no pipeline is created we currently have IID gap.
This is due to fact that we generate IID not on save,
but rather ahead of time. This results, us,
losing IIDs.

Properly expire all pipeline caches when pipeline is deleted

Closes #60469

See merge request gitlab-org/gitlab-ce!27334