Make teams to be maintainers of their code

This idea did spin as part of the conversation with @splattael.

Currently, we at Ops Backend unofficially do ten to organize the changes in modules. These changes are scoped to the team doing the changes. The scope is not about the team, but rather the set of functionalities implemented.

Consider that today on Ops Backend we have:

Ci:: - the #g_verify
Clusters:: - the #g_configure
Vulnerabilities:: - the #g_secure 
Serverlesss:: - the #g_serverless once added to GitLab

Other scopes would be:

Monitoring:: - all Prometheus/Error Tracing features
what else?
Deployments:: - #g_release?

If we could identify the scopes/categories of features maybe we could think about improving the role of reviewer/maintainer. Using Code Owners we could automatically assign reviewers from other teams when changes in given scope are done (ex. /clusters/).

Of course, it is impossible to categorize everything like that, but this would encourage to better modularize the codebase.

Maybe we could also improve the way how we see the role of Maintainer at GitLab. Each team is their own reviewer/maintainer of given scope, but team maintainer can become system-wide/GitLab Maintainer that foresee all codebase and understand the code architecture.

cc @DouweM @smcgivern @dhavens @DylanGriffith