Store pipeline creation rate limit into application settings

What does this MR do and why?

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/352232

It adds a new application settings column to be used for replacing the hardcoded value from !83969 (merged). The switch will be done in a follow-up MR because we need to change the value from 0 to 25 for .com.

Screenshots or screen recordings

$ bin/rails db:migrate
== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: migrating
-- add_column(:application_settings, :pipeline_limit_per_project_user_sha, :integer, {:default=>0, :null=>false})
   -> 0.0067s
== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: migrated (0.0068s)

== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: migrating
-- add_column(:application_settings, :pipeline_limit_per_project_user_sha, :integer, {:default=>0, :null=>false})
   -> 0.0083s
== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: migrated (0.0083s)


$ VERSION=20220503140817 bin/rails db:migrate:down:main
== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: reverting
-- remove_column(:application_settings, :pipeline_limit_per_project_user_sha, :integer, {:default=>0, :null=>false})
   -> 0.0047s
== 20220503140817 AddPipelineCreateLimitPerProjectUserShaToApplicationSettings: reverted (0.0073s)

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.