Optimize CI component fetching with request-scoped caching

What does this MR do and why?

Optimize CI component fetching with request-scoped caching

When a pipeline includes multiple CI components from the same project, each component triggers separate database queries and Gitaly calls for project lookup, SHA resolution, access checks, and content fetching.

This change introduces:

• SafeRequestStore caching for project, SHA, access checks, and catalog version lookups to avoid redundant queries within the same request

Behind the ci_optimize_component_instance_path feature flag.

Problem

When a .gitlab-ci.yml includes multiple components from the same catalog project:

include:
  - component: gitlab.com/my-org/components/component-a@v1.0
  - component: gitlab.com/my-org/components/component-b@v1.0
  - component: gitlab.com/my-org/components/component-c@v1.0

Each component triggered:

• 1 Project.find_by_full_path query
• 1 catalog version lookup query
• 1 Ability.allowed? check

For 3 components from the same project, this resulted in 3x redundant queries for identical data.

Solution

1. SafeRequestStore caching for:
   • Project lookup (keyed by project_full_path)
   • SHA resolution (keyed by project.id + reference)
   • Access checks (keyed by project.id + user.id)
   • Catalog version lookup (keyed by project.id + reference)

References

Related to #584405

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.