If we assume that there is value in pipeline users being able to expand templates w/o having to pre-identify them, then
1. we need to have self-identifying templates (for those we natively support); and
2. the easiest approach to self-identification is a schema (or is there another way?).

However, the existing basic template doesn't have a schema; it is essentially indistinguishable from FBC except for the fact that `olm.bundle` objects have only the `image` attribute.

Creating a schema means containing the existing attributes in that schema, for e.g.:

schema: olm.template.basic
entries:
- schema: olm.package
  name: rhbk-operator
  defaultChannel: stable-v24
- schema: olm.channel
  package: rhbk-operator
  name: stable-v24
  entries:
    - name: rhbk-operator.v24.0.3-opr.1
    - name: rhbk-operator.v24.0.4-opr.1
      skips:
        - rhbk-operator.v24.0.3-opr.1
      skipRange: '>=22.0.6-opr.1 <24.0.3-opr.1'

This is essentially a schema wrapper around a slice of `Meta` objects and can be expanded as such to create FBC, but at the cost of complexity to converting existing FBC to such a template.

Legacy basic template can be generated from FBC through a transform which essentially just strips all attributes from `olm.bundle` objects except the image attribute, like so:

yq eval 'select(.schema=="olm.bundle") = {"schema": .schema, "image":.image}' < existing-fbc.yaml > basic-template.yaml

New conversion requires moving all defined FBC attributes under `.entries[]` in addition to the `olm.bundle` attribute truncation. Is there a way to do this elegantly?