Experiment: Add reviewer roulette

What does this MR do?

This is an experiment: it's not a process we already committed to, it's very much up for discussions and feedback. And we don't have to follow roulette suggestions.

We currently depend on each developer knowing the domain expert for their specific MR and assigning them directly. We also use different tooling, see more in Add reviewer roulette to the runner project (#30915 - closed) to assist with this, but it runs locally on every developer machine.

This MR introduces the standard gitlab roulette with all it's existing features, such as:

1. Tracking PTO/busy status.
2. WIP limits via 2️⃣/9️⃣ in the status
3. using team.yml as a source for project reviewers/maintainers etc...

I took my previous changes from Add dangerbot to enable reviewer roulette (gitlab-pages!729 - merged) and Disable changelog danger rule (gitlab-pages!732 - merged) as the base for these changes.

Why was this MR needed?

I see a few potential advantages of this approach:

1. it's super easy for new contributors (like me 😂) to find the reviewer for simple changes.
2. we potentially may ask people from other parts of gitlab to become reviewers for runner. This can help a lot with the reviewer workload being distributed over a large pool of reviewers.
3. it does have some prebuilt mechanisms for distributing the load equally

Some potential disadvantages:

1. we currently require only a single approval from the runner maintainer, and don't have 2-stage reviews. And roulette assumes 2-stage reviews as default.
2. if we ask people from other teams to review our changes, then they may not spot problems early and significant re-work may be required when maintainer revies the code.

What's the best way to test this MR?

Just see the roulette commend below.

What are the relevant issue numbers?

Add reviewer roulette to the runner project (#30915 - closed)