Support defining metadata for the CI/CD templates

Problem

This is part of &6281 (closed) and &6293 (closed)

Proposal: Add metadata to the CI/CD templates

For fabricating the template information, we extend the capability of the CI/CD templates to have a structured metadata that can be populated on UI/API. This is something similar to the .properties.json file in GitHub Actions. Specifically, we'll introduce template keyword to .gitlab-ci.yml that consists of the following attributes:

Attribute	Description	Required	Default
name	The name of the template.	Yes
description	The short-description of the template.	No
icon	The icon of the template. Typically, the trademark of the programming language or the publisher.	No
maintainers	The maintainers of the template.	No
authors	The authors of the template.	No
categories	The categories of the template, for example, Testing, Golang, Deploy etc	No
file_patterns	The file patterns to show the relevancy, for example, if the project contains *.rb or Gemfile file, a ruby template is shown as relevant one.	No
usage	How to use the template. See below for more details.	No	copy-paste
inclusion_type	How to use the template when usage is inclusion. See below for more details.	No

The details of usage attributes:

Value	Workflow management	Description
copy-paste	Decentralized	The template is copy-pasted into a project workflow file and customized/versioned in each repository. This is the tradional behavior of GitLab templates that provide a starter content to be a new instance, like Issue/MR templates.
inclusion	Centralized	The template is included into a project workflow file and customized/versioned in the other/central repository. This is the unique concept in GitLab CI/CD that directly consumes a template.

The details of inclusion_type attributes:

Value	YAML anchors only?	Global keyword exists?	Jobs defined?	Description
shared-workflow	No	Yes	Yes	The end-to-end CI/CD workflow to be shared with the other projects.
workflow-extension	No	Yes	No	The extension of the workflow-level configs (i.e. global keywords) to be shared with the other projects.
composable-job	Yes	No	No	The YAML anchors to be included into the project workflow for composing a job with extends or !reference.
other	Any	Any	Any

NOTE: YAML anchors is a hidden configuration to be used with extends.

Usage Examples per inclusion_type

`shared-workflow`

Template

template:
  name: AWS Auto Deploy
  usage: inclusion
  inclusion_type: shared-workflow

stages:
  - build
  - test
  - review
  - deploy
  - production
  - cleanup

variables:
  AUTO_DEVOPS_PLATFORM_TARGET: ECS

include:
  - local: Jobs/Build.gitlab-ci.yml
  - local: Jobs/Deploy/ECS.gitlab-ci.yml

Project workflow file (If a project uses multiple workflows)

# A shared workflow is initiated as a child pipeline.
# Since the shared workflow is sandboxed as an individual pipeline, it doesn't affect the
# project specific workflow. They can even customize the order of the job/stage executions
# to run a shared workflow at a desired point.
<shared-workflow-name>:
  stage: .pre
  trigger:
    include:
      - project: <template-project>
        ref: <version>
        file: <template>
  strategy: depend

# Project specific workflow
build:
  stage: build
  script: echo 'Project-specific build script'

test:
  stage: test
  script: echo 'Project-specific test script'

deploy:
  stage: deploy
  script: echo 'Project-specific deploy script'

Project workflow file (If a project uses the single workflow)

# A shared workflow is direcly imported into the project workflow.
# In this case, the project specific workflow could be limited/affected by the shared workflow.
include:
  - project: <template-project>
    ref: <version>
    file: <template>

`workflow-extension`

Template

template:
  name: Merge Request Pipelines Configuration
  usage: inclusion
  inclusion_type: workflow-extension

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_IID
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Project workflow file

include:
  - project: <template-project>
    ref: <version>
    file: <template>

# Project specific workflow
build:
  stage: build
  script: echo 'Project-specific build script'

test:
  stage: test
  script: echo 'Project-specific test script'

deploy:
  stage: deploy
  script: echo 'Project-specific deploy script'

`composable-job`

Template

template:
  name: Accessibility Test Job
  usage: inclusion
  inclusion_type: composable-job

.accessibility-test: &accessibility-test
  image: registry.gitlab.com/gitlab-org/ci-cd/accessibility:5.3.0-gitlab.3
  script: /gitlab-accessibility.sh $a11y_urls
  artifacts:
    when: always
    expose_as: 'Accessibility Reports'
    paths: ['reports/']
    reports:
      accessibility: reports/gl-accessibility.json

Project workflow file

include:
  - project: <template-project>
    ref: <version>
    file: <template>

# Project specific workflow
build:
  stage: build
  script: echo 'Project-specific build script'

test:
  stage: test
  script: echo 'Project-specific test script'

a11y:
  stage: test
  extends: .accessibility-test

deploy:
  stage: deploy
  script: echo 'Project-specific deploy script'