Improve automation around `kubectl` versions to include in images

[mallardduck]

This issue is to track the initial phase steps to add basic metadata to Rancher release branches to track supported k8s versions. The goal is to add in additional metadata to build.yaml in the r/r repo that we can then consume to know what versions to target.

---

Implementation Details

Essentially this means adding a new field to build.yaml on each active branch. For main branch or 2.11, we would expect this to look like:

kubernetesVersions: [v1.29, v1.30, v1.31, v1.32]

This field does not need to be rendered into the constants.go file that build.yaml generates into.

---

Future Consideration

Once implemented in each current release branch of Rancher, we could create a new rancher/k8s-metadata repo to aggregate these datapoints into a single location. This can improve the UX/DX of accessing this data allowing for it to be more easily used in CI/CD contexts. This could be

[mallardduck]

rancher/rancher#48601

[mallardduck]

Moving to blocked due to current bandwidth and because this depends on k8s metadata side project I've started.

[mallardduck]

This PR works to improve this massively: #119

Now this repo is fully at a state where it could be driven by updates from a r/r core canonical location. Because we simply track the versions in the most simple form, then having Rancher define constants of those versions (or the range) will be good enough for our need.

For instance, we're now equipped to try out a few new automations for managing this repo. 1. we could create a GHA that check rancher's k8s versions (based on defined minor target), then automatically keep ours in range. I.e. If rancher drops support for a k8s version ever, then this repo can create PRs to respond. Similarly - would use the same scripts - when branching occurs this could help ensure we keep our branches in sync too. (e.g. when r/r branches, we update to create a new branch pointing to that; then main branch stays tracking rancher main)