Revisit the BundleDeployment API's UX after the latest API overhaul

[timflannagan]

Follow-up to #293 which overhauled the BundleDeployment API to support the dynamic creation of Bundle contents.

Goal: revisit the status.installedBundleName and the custom printer columns.

Currently, the UX around the BD's printer column output can be confusing, especially in the case where a generated BundleA was successfully created/unpacked/installed, and the BD was updated with a different desired configuration, and the generated BundleB fails to unpack/install. In this case, the printer columns signal that there's still a successful installation as BundleA is still active, which can be confusing.

One implementation may be centered around using the Deployment/ReplicaSet status fields to derive printer columns (e.g. Ready/Available/etc.), and refactor the BD's printer columns to use boolean types to help communicate the current state of a resource vs. relying on string values which are difficult to accurately portray the full picture of the current state.

[exdx]

UX may include a numeric status: 0/1 or 1/2 available during a pivot that fails.

The UX may be informed by a higher level component (like deppy) handling this status and keeping the rukpak layer straightforward.

[timflannagan]

Related to https://github.com/operator-framework/rukpak/issues/403 which can be a short term UX win.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.