Backend: Allow interpolation to use local context data

Problem

1. As a user I would like to create a component that uses a container image that is also built during the release process of the component itself. For example:

• I tag version 1.0 of the repo.
• A tag pipeline runs and build the Docker image my-image:1.0
• The component yaml file uses by default the image that matches the same tag.

This problem cannot be solved using predefined CI variables because those are evaluated in the context of the consumer project, not the current file being evaluated.

Proposal

We can make the component ref related to the current file context available for interpolation. For example:

# template.yml
my-job:
  image: "$CI_REGISTRY_IMAGE/project-path:$[[ context.ref ]]"

Workaround

The current workaround would be to either specify the component version twice: once in the include of the component and another as input for the component that is then being used to reference the image.

Another option is to reference the image version in the pipeline template file in a commit just before creating the tag. So that the git revision content hardcodes the tag.

Technical Details

Currently, we skip the interpolation process if an included CI config file has no header. We do this to save on processing time because interpolation is expensive, and so far it's been okay because the only values available for interpolation are inputs and they must have a header. However, the new context interpolation option does not require a header so we need to remove this check. Performing interpolation on all included CI config files may significantly degrade performance, so we need to instrument interpolation to ensure this doesn't happen. If we can remove the CI header check without degrading performance, we can implement $[[ context.ref ]] as described in this issue. Otherwise we'll need to find another solution.