RubyGems API skeleton and authentication [RUN ALL RSPEC] [RUN AS-IF-FOSS]

🌏 Context

We are adding support for RubyGems in the GitLab package registry. This is the first of many MRs that will build out the API, models, and services needed to interact with the Gem client (gem push foo), and Bundler (bundle install). The goal of this MR is to set up the skeleton of the API behind a feature flag so we can start building out the various pieces that go along with each endpoint. In addition to defining the various routes, we also set up authentication here.

🔬 What does this MR do?

1. Adds rubygems_packages.rb with a collection of empty endpoints to support the RubyGems API
2. Adds a new feature flag :rubygem_packages that will stand in front of the entire API.
3. Adds :token_auth as a supported authentication type in API::Helpers::Authentication and adds a new set of resolvers.

🔒 What are authenticate_with and API::Helpers::Authentication? Why don't we use the normal API authentication?

API::Helpers::Authentication was recently added as the beginning of a refactor to the existing API authentication. When dealing with various package managers, we don't have the ability to choose how they will send credentials to the API. For example, if we want to accept a personal access token or deploy token from NPM, we have to accept them through Oauth headers even though they are not OAuth tokens. This has made it difficult to follow the authentication code, especially with regards to the package managers.

API::Helpers::Authentication introduces a new workflow that allows you to decorate your API class with something like:

    authenticate_with do |accept|
      accept.token_types(:personal_access_token_with_username, :deploy_token_with_username, :job_token_with_username)
            .sent_through(:basic_auth)
    end

making it much easier to understand which authentication methods are used and which token types are accepted. Currently only the NuGet API uses this new module, but the plan is to refactor all of the package APIs over to it, and eventually the non-package APIs. Since we are adding a new package type here, we should use the new Authentication module rather than creating technical debt that we would need to refactor later.

☑ Does this MR meet the acceptance criteria?

Conformity

• [-] Changelog entry Behind a feature flag
• [-] Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• [-] Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Related to #299262 (closed)