Only allow classes and modules directly under the Gitlab namespace for truly cross-cutting concerns

In #212156 (closed) / !51236 (merged), we required all new classes to be namespaced. This is because, say, an Issue class might mean different things in the different domains that GitLab operates in.

However, one get-out for this is the Gitlab namespace. We have a lot of classes and modules directly under this namespace: https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab. Anything under here won't be detected by the previous MR, because it's not at the top level. But it being nested under Gitlab:: tells us nothing about the domain.

Some of these will be fine: they will represent items that aren't part of any domain except GitLab-the-application as a whole. Gitlab::Popen is a reasonable example here.

However, we also have things like Gitlab::SubmoduleLinks, which clearly belong to a particular domain (Category:Source Code Management), and we should be able to detect and move those over time.

In !51236 (comment 485374321) @fabiopitino suggested a general reorganisation:

The problem is that Gitlab:: contains both domain code as well as infrastructure code. These 2 layers should live in different directories.

One goal we could aim to is to eventually move to a different directory structure like:

domains/
  ci/
    models/
    controllers/
    finders/
    lib/
  merge_requests/
  issues/
  projects/
gitlab/
  auth/
  database/
  elasticsearch/

Where each domain has its own lib folder. This means that classes like Gitlab::Ci::Config will become simply Ci::Config as it's part of Ci:: domain. Then Gitlab:: namespace will represent the infrastructure code.

Which might be a good goal to aim for. For now, we can update the existing check to ignore Gitlab::, perhaps?