`dry-run:schedule` for now will only run the first schedule from the variants

I realized this when I was thinking how to dry-run some of the schedules. The problematic code is in Schedule::Manager#find_schedule!:

def find_schedule!(project_path)
  schedules_specification.find do |spec|
    spec.project_path == project_path
  end ||
    raise(
      InvalidDryRunScheduleName,
      "Cannot find schedule named #{project_path.inspect} in #{raw_schedules_path}")
end

It's using find to find the first matching specification, however, there can have multiple ones with the same project_path. find is a linear search, so we always return the first one.

For example, in the current schedule gitlab-org/gitaly, there are two schedules underneath:

gitlab-org/gitaly:
  base:
    variables:
      TRIAGE_SOURCE_TYPE: projects
      TRIAGE_SOURCE_PATH: 2009901
  variants:
    - id: 29054 # https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29054/edit
      active: true
      description: '[DAILY] gitlab-org/gitaly'
      variables:
        # hygiene
        TRIAGE_LABEL_ACCEPTING_MERGE_REQUESTS: 1
        TRIAGE_LABEL_MISSED_SLO: 1
        TRIAGE_LABEL_REMINDERS: 1
        TRIAGE_MOVE_MILESTONE_FORWARD: 1
    - id: 29055 # https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/29055/edit
      active: true
      description: '[WEEKLY] gitlab-org/gitaly'
      cron: '0 0 * * 1'
      variables:
        # package
        TRIAGE_COMMUNITY_MERGE_REQUESTS: 1
        TRIAGE_MISSING_CATEGORIES: 1
        TRIAGE_TEAM_TRIAGE_PACKAGE: 1

For now it'll only dry-run the first one (daily), ignoring the second one (weekly)

This might not be important to fix before we actually need it, but we need to know this limitation.

/cc @gl-quality/eng-prod