Paginate group runners in project CI/CD settings

Summary

Similar to #31159 (closed), we should paginate the group runners on a projects CI/CD Settings page to prevent slow loading and increase responsiveness of this page. A group with roughly 10,000 runners can experience a minimum of 15s to load the settings page.

Steps to reproduce

1. Find a group with a large (1000+) amount of group runners registered at the top level group.
2. Attempt to load <group>/<project>/-/settings/ci_cd and observe the slow performance.

Example Project

See ZD Ticket: https://gitlab.zendesk.com/agent/tickets/219744

What is the current bug behavior?

<group>/<project>/-/settings/ci_cd takes a very long time to load and expanding the Runners section shows a very long list of group runners.

What is the expected correct behavior?

<group>/<project>/-/settings/ci_cd should be speedier to load and group runners are paginated.

Relevant logs and/or screenshots

See ZD Ticket for performance profile

Output of checks

This happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Similar work was done in !45830 (merged)