Improvements in OCP4.15 make it possible for catalogsource images to contain only catalog(& optional cache) if the catalogsource CR `spec.properties.grpcPodConfig.properties.extractContent` cacheDir/catalogDir are set.

We need to improve tooling to support the binary-less catalog experience, specifically:

1. expose a new binary-less path to `opm generate dockerfile` which builds on scratch both up- and down-stream, one concept of which could be:

   FROM quay.io/operator-framework/opm:v1.41.0 as builder
   
   # Copy FBC root into image at /configs and pre-populate serve cache
   ADD catalog /configs
   RUN ["/bin/opm", "serve", "/configs", "--cache-dir=/tmp/cache", "--cache-only"]
   
   FROM scratch
   
   COPY --from=builder /configs /configs
   COPY --from=builder /tmp/cache /tmp/cache
   
   # Set FBC-specific label for the location of the FBC root directory
   # in the image
   LABEL operators.operatorframework.io.index.configs.v1=/configs

2. express the cache location via a new label unless cacheless catalogs are implemented in the same period
3. update ose-operator-registry endpoint to anticipate serving FBC instead of SQLite
4. determine if we need to maintain a binary-catalog-base as well as a binary-less-base only (aka who do we discover depended on self-running catalog images?)
5. update documentation illustrating how to generate & validate the cache for such an image (ideally, the end-to-end binary-less flow), taking into account:
   1. generic operator-author persona
   2. konflux operator-author persona
   3. other personas?