Version processing for custom components

[timuthy]

How to categorize this issue?

/area ops-productivity
/area delivery
/kind enhancement

What would you like to be added:
GLK should support translating version and OCI reference information for any resource, especially those belonging to components not integrated into GLK, whether in the base or landscape repository.

Generally, GLK won't generate resources for a custom or private Gardener extension (i.e., one with non-public source code). At the same time, the component may be included in an OCM image vector, requiring operators to extract version or OCI reference information to create the appropriate extension resources or image vector overwrites.
Since the landscape kit already knows how to process and translate OCM information, it can assist operators in doing the same for custom extensions or components.

A generic mapping is required to match OCM information to the target resource.
One idea discussed @LucaBernstein and @MartinWeindel was to let operators create .tpl files in the target (base or landscape) repository using well-known variables.

dev-landscape/components/private-extension/extension.yaml.tpl:

apiVersion: operator.gardener.cloud/v1alpha1
kind: Extension
metadata:
  name: provider-private-cloud
spec:
...
      helm:
        ociRepository:
          repository: {{ .ocm.provider-private-cloud.extension.oci.repository }} # mapping to OCM component
          tag: {{ .ocm.provider-private-cloud.extension.oci.tag }} # mapping to OCM component
      values:
        imageVectorOverwrite: |
          images:
          - name: private-cloud-controller-manager
            repository: some.private.mirror.com/private-cloud-controller-manager
            tag: v1.2.3

glk generate then detects these .tpl files and rewrites them with the resolved variables. Of course, the newly generated files can be combined with Kustomize again to create proper overlays.