Fix AKS nodegroup upgrade validation

[mantis-toboggan-md]

Summary

Fixes #12862

Technical notes summary

This is a follow on from #12532 We started using semver.coerce on the AKS cluster version because it may not specify a patch version (eg if provisioned outside rancher, "1.30" would be a valid cluster k8s version). Consequently the originalVersion prop went from being a string to a semver object. This appears to be mostly fine, as we are mostly using semver to compare versions and semver doesn't care; however, in nodegroups we are merely checking if versions are equal and use a simple equality comparison.

I think the simplest fix is to make sure that originalVersion is a string again. I verified that this change wont re-introduce #12525 by double-checking that semver.coerce("1.30").version === "1.30.0"

Areas or cases that should be tested

1. Create a new AKS cluster with some version less than the latest available version
2. wait for provisioning to complete
3. edit the cluster and select a new kubernetes version. Check for version comparison regressions:
   • the cluster version dropdown should not list any versions older than your current version
   • when a new cluster version is selected an info box should appear in node group tabs
4. Edit the cluster again, and verify a couple things:
   • node groups now have a checkbox to upgrade their version
   • if a new cluster version is selected(again), node groups no longer have the upgrade option and show a checkbox instead
5. Keep the cluster version unchanged, and select the node group upgrade checkbox, save the cluster
6. Edit the cluster again and verify that the nodegroup now has the same version as the cluster.

Areas which could experience regressions

anything to do with version comparison in the aks form - I believe I've covered all cases in the above section.

Screenshot/Video

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

[rak-phillip]

LGTM