Update ResourceType version fields to use Versions instead of Releases

What does this MR do and why?

Background:

With !134148 (merged), a catalog resource Version is created upon Release creation if the commit has valid components. A Version is essentially a Release in the context of catalog resources. The table catalog_resource_versions has a 1:1 relationship with releases.

So far, we have been using project Releases as the logic for Versions. Now we need to replace the logic from catalog_resource.project.releases to catalog_resource.versions.

This is MR #2 of 3 MRs to handle the logic migration.

This MR:

• Creates Types::Ci::Catalog::Resources::VersionType to replace ReleaseType when resolving versions.
  • VersionType is structured as a lightweight version of ReleaseType. It supports all the fields that the FE currently needs in the GraphQl ciCatalogResource(s) queries.
  • Creating this new Type is simpler than updating the Version model to support all the ReleaseType fields. It allows us to avoid further N+1 challenges.
• Moves Ci::Catalog::VersionsResolver to Ci::Catalog::Resources::VersionsResolver to be consistent with the naming convention of the Ci::Catalog::Resources::Version model.
• Updates VersionsResolver and the latest_version resolver to use VersionsFinder instead of ReleasesFinder.
• Addresses minor spec refactoring suggestions on spec/finders/ci/catalog/resources/versions_finder_spec.rb from #431249 (closed).

User facing changes:

These changes do not break the existing GraphQL queries that FE currently uses for the Ci Catalog feature. See !135669 (comment 1630690514). The only visible change is that Versions are outputted instead of Releases for catalog resources.

A Feature flag is not required for the GraphQl fields since they are in alpha. Also, the Ci catalog resource is still in Experimental phase.

Partially resolves #429707 (closed).

How to set up and validate locally

Before checking out this branch, we should ensure the behaviour has not changed by comparing the GraphQl outputs before and after.

1. Checkout the master branch (and restart gdk if necessary).
2. Set up at least two new catalog resources, each with at least 2 releases which you can create via the UI.
3. Go to http://gdk.test:3000/-/graphql-explorer and run the following queries (update the id argument as necessary). Make note of the outputs.

(This is the FE query from get_ci_catalog_resource_readme.query.graphql and get_ci_catalog_resource_shared_data.query.graphql using CatalogResourceFields)

query {
  ciCatalogResources {
    nodes {
      id
      name
      latestVersion {
        id
        tagName
        tagPath
        releasedAt
        author {
          id
          name
          webUrl
        }
      }
    }
  }
}

(This is the FE query from get_ci_catalog_resource_details.query.graphql)

query {
  ciCatalogResource(id: "gid://gitlab/Ci::Catalog::Resource/1") {
    id
    name
    versions(first: 1) {
      nodes {
        id
        commit {
          id
          pipelines(first: 1) {
            nodes {
              id
              detailedStatus {
                id
                detailsPath
                icon
                text
                group
              }
            }
          }
        }
        tagName
        releasedAt
      }
    }
  }
}

4. Now checkout this branch (and restart gdk). Re-run the queries from Step 3. Observe that the outputs are the same as they were in Step 3 except that the version ID returned is of a VersionType object instead of a ReleaseType object. (i.e. gid://gitlab/Ci::Catalog::Resources::Version/2 instead of gid://gitlab/Release/2).

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 #429707 (closed)