What this PR does / why we need it

Let's try to eat our own stuff and build a component version of the OCM CLI like OCM v1 and then push our component version to a CTF.

What was added:

• A taskfile extension that can
  • build the CLI for windows,linux,darwin(mac) in arm64,amd64
  • build a component-constructor.yaml from resource fragments
  • build a ctf based on the component-constructor.yaml containing a component version of the OCM CLI in various build formats
  • verify the ctf by downloading the resource and running the CLI again
• An extension to OCM download resource that can (just like old ocm), use a label that hints towards a relative path under which the resource should be stored (downloadName). This path is used in favor of the resource name if found and no output name is defined.

What is missing compared to the OCM CLI v1 right now:

• we do not have an ocmcli-image resource yet (the docker input method would be needed for this or we build the image separately and add it as an access, TBD)
• while coding I noticed that I still need to pass the resource version as part of the identity for the download, this needs to be fixed up (on this right now, but this is part of a fix for the OCI bindings)
• We dont have component constructor templating (we maybe never will have) and so i am using native templating via environment variables and shell scripts

Which issue(s) this PR fixes