Add GraphQl full_path field to ResourceType

What does this MR do and why?

In #450914 (closed), we discovered that the web URL generated for projects listed on the CI/CD Catalog explore page breaks on GitLab instances hosted on relative URLs.

This problem occurs because the FE generates the links for the CI/CD Catalog listing by appending the project's webPath to /explore/catalog. However, a "web path" also includes the relative gitlab base URL, which breaks the link because it's not recognized as a project path.

The fix is to expose the project's fullPath field, which is done in this MR. Then after this is deployed, frontend can use fullPath instead of webPath only where necessary. Some links still need to continue using webPath as explained in #450914 (comment 1832330110). For this reason, this MR adds the field fullPath and does not remove/replace the value of webPath.

Resolves #450914 (closed).

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

The below screenshot shows the GraphQl output when GitLab is hosted on a relative URL at /gitlab. Observe the fullPath field returns only the project path, whereas webPath returns the project path along with the relative base.

How to set up and validate locally

1. Set up at least one catalog resource on your local gdk.
2. In the GraphQL explorer, test this query:

query getCatalogResources {
  ciCatalogResources {
    nodes {
      id
      fullPath
      webPath
      name
    }
  }
}

3. The result should include the expected fullPath value.

Related to #450914 (closed)