[CRD Upgrade Safety] Add a change validation for handling field type changes

[everettraven]

It is considered a breaking change to update the type of a field when upgrading a CRD. We currently do not have an explicit check for this type of change so we get an output similar to:

message: 'validating upgrade for CRD "nginxolm75123s.cache.example.com" failed:
      CustomResourceDefinition nginxolm75123s.cache.example.com failed upgrade safety
      validation. "ChangeValidator" validation failed: version "v1alpha1", field "^.spec.field"
      has unknown change, refusing to determine that change is safe'

We should add a new change validation that explicitly handles this case to improve the UX in identifying the exact reason why a CRD upgrade was rejected and help users make better informed decisions as to if this is a change they are comfortable with going through on their cluster.

This is not a v1.0.0 blocker as it is a QoL improvement and the existing pre-flight check fails closed on an unrecognized change so we aren't causing any harm to a user's cluster with the current state of the check.