Add cascading package forwarding setting columns

What does this MR do and why?

The package registry has a set of settings that allow forwarding of requests for packages to external public registries. For example, a user could request npm install vue pointing to their GitLab project, and if the package is not found in that project, the request is forwarded to npmjs.org.

Currently, these settings live at the instance level in the application_settings table. We would like to give control over these settings to individual groups by adding them at the namespace level. Additionally, we are planning on including cascading logic with these settings where if a given namespace has not explicitly set the forwarding setting, it inherits from it's parent namespace. We have a framework for cascading settings: https://docs.gitlab.com/ee/development/cascading_settings.html. In order to use it, we need to have:

1. <setting_name> and lock_<setting_name> columns in the application_settings table.
2. <setting_name> and lock_<setting_name> columns in the namespace_package_settings table.

There is a helper to create these columns, but that helper only works if none of the columns exist yet. In our case, we already have <setting_name> in the application_settings:

# already in application_settings
maven_package_requests_forwarding
pypi_package_requests_forwarding
npm_package_requests_forwarding

So in this MR, we add the remaining columns so we can utilize the CascadingNamespaceSettingAttribute concern:

# in namespace_package_settings
maven_package_requests_forwarding
lock_maven_package_requests_forwarding
pypi_package_requests_forwarding
lock_pypi_package_requests_forwarding
npm_package_requests_forwarding
lock_npm_package_requests_forwarding

# in application_settings
lock_maven_package_requests_forwarding
lock_pypi_package_requests_forwarding
lock_npm_package_requests_forwarding

If you'd like to see how these columns will be used, that work is being completed in !99285 (merged), which will follow this MR. I considered putting that logic in this MR too, but as you can see, it would start to become quite large, so I decided to split out the database changes.

Screenshots or screen recordings

N/A

How to set up and validate locally

Run the migrations and roll them back to ensure they are successful.

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.

Related to #360267 (closed)