render: support rendering FBC from bundle directories

[joelanford]

Description of the change:
This PR adds support to the opm render command for bundle directories.

When rendering bundle directories, there is no metadata about the bundle image reference, so the FBC rendered from a bundle directory contains inlined olm.bundle.object properties but lacks an image value.

However callers of opm render with bundle directories will generally know the image that will contain the bundle directory, so they can insert the bundle image reference themselves. To facilitate this image reference injection, this PR adds a --image-ref-template flag that supports templating based on package, name, and version of the bundle.

If specified, render will populate olm.bundle objects' image field with the templated value and use the olm.csv.metadata property. If not specified, render will leave the image field empty and will instead include all of the bundle manifests in the catalog as olm.bundle.object properties.

Motivation for the change:
Some catalog pipelines build the bundle images based on the bundle sources that are included in a source repository. This structure works well in imperative flows where bundle sources alone are sufficient to construct a valid catalog.

However with catalogs themselves now being declarative, a new use case has appeared. Operator authors would like to be able to provide the pipeline with their bundle sources and their catalog metadata. But there is a chicken and egg problem because existing opm tooling only supports generating catalog metadata from a bundle image. If a pipeline builds the bundle images and opm expects the bundle images to exist in order to generate catalog metadata, it is impossible for an operator author to provide catalog and bundle sources at the same time.

In order to fully support this style of pipeline, a follow-on PR may be necessary to update opm's template to support using bundle directory references and supplying an image reference template.

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Docs updated or added to /docs
• Commit messages sensible and descriptive

[codecov]

Codecov Report

Attention: Patch coverage is 72.22222% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 53.88%. Comparing base (d74ce59) to head (8b20b15).
Report is 6 commits behind head on master.

Files	Patch %	Lines
alpha/action/render.go	72.22%	10 Missing and 10 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #748      +/-   ##
==========================================
+ Coverage   53.80%   53.88%   +0.08%     
==========================================
  Files         108      108              
  Lines       10368    10436      +68     
==========================================
+ Hits         5578     5623      +45     
- Misses       3808     3823      +15     
- Partials      982      990       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joelanford]

/hold
We might not need this, at least not urgently.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: joelanford

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [joelanford]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[grokspawn]

/lgtm

[grokspawn]

/lgtm