feat: Add ProductImage::product_version function

[razvan]

Description

Needed for stackabletech/hbase-operator#506

Useful for operators that need to support incompatible product versions.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

# Author
- [x] Changes are OpenShift compatible
- [x] CRD changes approved
- [x] Integration tests passed (for non trivial changes)

# Reviewer
- [ ] Code contains useful comments
- [ ] (Integration-)Test cases added
- [ ] Documentation added or updated
- [ ] Changelog updated
- [ ] Cargo.toml only contains references to git tags (not specific commits or branches)

# Acceptance
- [ ] Feature Tracker has been updated
- [ ] Proper release label has been added

[nightkr]

Functionality LGTM, could use a more descriptive PR title

[sbernauer]

Honestly I would like to object this change. Yes, currently we can save ~ 10 CPU cycles :D, but in the future we will have
not only automatic stackable version detection, but the operator might also automatically pick the product version for you (probably from the LTS line).
This might involve network calls or some constants compiled in the code or something completely else.

I would prefer to not build on the fact that the product version determination is currently cheap (n network call) and simple.

For now I would prefer sticking to product_image.resolve().product_version.

[razvan]

I can revert if this is a veto. No problem.

Though I agree that the code comment insinuates this is about saving CPU cycles, it was more about failing fast and having concise code.

[sbernauer]

I guess you are right, I forgot about the need of passing image_base_name: &str, operator_version: &str to resolve.
So let's keep the API as you have introduced it ;)

I created a PR for a small refactoring, would be awesome if you could have a look! #818