feat: Add ability to select version of demos/stacks

[NickLarsenNZ]

Once demos are versioned per release (see sub-issue) DONE, we should be able to select which demo/stack version to install.

Suggested option to add:

stackablectl demo in monitoring --release 24.7

The default should be the latest stable release.

Examples (competing ideas, in no particular order)

stackablectl demo in monitoring # latest stable. Currently this deploys manifests from `main`

# Enforce a particular release
stackablectl demo in monitoring --release 24.7
stackablectl demo in monitoring --release dev

# Take any committish (stackableRelease derived from stack.yaml at that version)
stackablectl demo in monitoring --ref abcdef7
stackablectl demo in monitoring --ref release-24.7

# Or, enforce a branch (because the HEAD is what should be working. Random commits might cause surprises)
stackablectl demo in monitoring --branch release-24.7 # but must be a branch

Considerations:

• --ref (Committish), or --branch (and check that it is a branch), or --release (we need to derive the ref).
  • We can work out the operator release, because at that version
  • We should ideally go with the most flexible (--ref), unless we cannot derive the release.
  • ⚠ There will still be hard coded refs in the stack/demo yamls, as well as scripts. This can lead to broken demos.
  • Specifying --release would remove the need for the stackableRelease key in stacks.yaml.
• Caching - do we need to invalidate the cache if a ref/branch/release is specified?
• Overlap with: 'install' should install 'stable' instead of 'nightly' for operators/demos/etc... #212

[NickLarsenNZ]

Not having this is making things really difficult at release time, because the current behaviour:

• requires the demos main branch to be stable, which means...
• changes needed for an upcoming release need to be held back in a next branch (which still can't be used by stackablectl without checking out the branch), and then...
  • The next branch gets mixed with changes that can work for the next release, as well as other changes that break it (eg: image tags that don't yet exist). This confusion could be avoided by using the 0.0.0-dev tags.
• Near release time, the next branch gets merged - generally breaking the stability promise of the main branch.

Notes:

• No other repos at stackable treat main as a stable source, so demos should not either.
• Demos are now versioned, so we only need to do this change before the demos main branch can be treated as dev/nightly/unstable.

[labrenbe]

We decided to implement the first option --release because users would typically want to install a stable version (--release dev still allows installing from main) while keeping the overall complexity as low as possible.