The composite template currently issues several `docker run` commands based on the base image which contains opm, to ensure that the same version is used for build/verify/serve. However, the run does not pass through authentication configuration available to the author where the top-level operation is run. Repositories like registry.redhat.io are private and we expect most operator-authors to be generating their catalog contributions against them.  

Modify the implementation to no longer extract opm from the provided baseImage in the spec and instead process the specified templates internally.  That is, instead of:

1. pull baseImage docker
2. foreach fragment in the composite template
   1. shell out to docker to run an instance of that image and use it to generate the contribution fragment

 we will now do:

1. foreach fragment in the composite template
   1. invoke the library to generate the contribution fragment

This is a reduction in capability since we cannot guarantee the version of opm that is used to render contributions, but this is a good compromise in terms of unblocking the pipeline.

A/C:

• user can create contributions of all supported builder types (semver, basic, raw, custom) which refer to base images homed in private repositories (registry.redhat.io/openshift4/ose-operator-registry:v4.12, quay.io/operator-framework/opm:v1.26.3)
• documentation of the methodology if it's not "just handled for the author".
• utest/e2e test of the methodology if not ^^^^