Draft: Consolidate read_pipeline and read_pipeline_schedule permissions

What does this MR do and why?

This MR removes the read_pipeline_schedule permission in favor of read_pipeline.

The included spec in the first commit or this MR shows that these 2 permissions have the same behavior for all user roles and project visibility levels.

Looking through the git history, it also seems that this permission was added

Screenshots or screen recordings

> ProjectPolicy.ability_map.map.select { |k,v| k.match(/read_pipeline/) }
=> {:read_pipeline=>
  [[:enable, #<Rule can?(:reporter_access)>],
   [:prevent, #<Rule any?(all?(builds_disabled, ~internal_builds_disabled), repository_disabled)>],
   [:prevent, #<Rule repository_disabled>],
   [:enable, #<Rule can?(:public_access)>],
   [:enable, #<Rule all?(public_builds, can?(:guest_access))>]],
 :read_pipeline_schedule=>
  [[:enable, #<Rule can?(:reporter_access)>],
   [:prevent, #<Rule any?(builds_disabled, repository_disabled)>],
   [:prevent, #<Rule repository_disabled>],
   [:enable, #<Rule can?(:public_access)>],
   [:enable, #<Rule all?(public_builds, can?(:guest_access))>]]}

> Ci::PipelineSchedulePolicy.ability_map.map.select { |k,v| k == :read_pipeline }
=> {:read_pipeline=>[[:prevent, #<Rule all?(~can?(:read_build), ~external_pipeline)>]]}

> Ci::PipelinePolicy.ability_map.map.select { |k,v| k == :read_pipeline }
=> {:read_pipeline=>[[:prevent, #<Rule all?(~can?(:read_build), ~external_pipeline)>]]}

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.