Use nested structure to organize CI classes

Problem

Today classes related to CI domain under app/ are mostly organized in a flat structure. This organization makes it hard to understand the domain because:

1. It's not clear what are all the main components
2. It's not clear whether a component has private or sub components
3. It's hard to enforce boundaries to decouple components when we don't know (1) and (2)

Proposal

Following on #207480 (closed) I propose we organize our classes in a tree structure by nesting components when:

1. They are private to the top level component (e.g. see build/metadata.rb)
2. They are specific types of the top level component (e.g. see variable/job_variable.rb)
3. They extend functionality of the top level component (e.g. see pipeline/schedule.rb)

app/models/ci
  - bridge
  - build
    - build/metadata
    - build/need
    - build/runner_session
    - build/trace
      - build/trace/chunk
      - build/trace/section
      - build/trace/section_name

  - group
  - job_artifact
    - job_artifact/blob
  - persistent_ref
  - pipeline
    - pipeline/persistent_ref
    - pipeline/chat_data
    - pipeline/config
    - pipeline/enums
    - pipeline/schedule
  - processable
  - ref
  - resource_group
  - resource
  - runner
    - runner/runner_namespace
    - runner/runner_project
  - stage
  - trigger
    - trigger/request
  - variable
    - variable/pipeline_schedule_variable
    - variable/pipeline_variable
    - variable/group_variable
    - variable/job_variable

The following principle could be applied to other directories: services, finders, serializers, etc.