Add automation to charm repos to track their associated rock, warn if we are not using the latest rock

Context

For rocks we produce, we use the tagging scheme <upstream-version>-<commit>, where the commit is the implicit version for our rock (eg: if we edit the rock built for a given upstream version). For charm repositories that use these rocks, this can make it tough to know if the charm repo is using the "correct" image (likely, the most up to date image for that release track). We should implement some automation to make this clearer.

This would also be helpful for reviewing PRs. We could implement CI similar to the charm library checks that warn on a PR if an image is out of date. This shouldn't block the PR (in case the old image is intentional), but it would be a helpful check. For similar reasons, we could make general maintenance of our charm easier by adding periodic CI that checks if rocks are up to date for a charm, possibly even opening a PR for bumping the image automatically.

Some complications to consider:

because our gh repos house multiple rocks, the "correct" image might not have the most recent commit ID
different charm releases (eg: track/1.1 and track/1.2 of a given charm) will often follow different rock releases (eg: charm 1.2 needs the rock for 1.2), so however we implement this we need to be able to differentiate the tracked image per charm track

What needs to get done

TBD - needs to be decided during initial work

Definition of Done

TBD - needs to be decided during initial work

canonical / kubeflow-rocks