Enhancements to CRD version management

See notes in https://docs.google.com/document/d/1TdDas13UbA_KrCOUmkVEVvsyX_0twQmu4yBEZE9jTPk/edit?tab=t.0

Epic Goal

Enhance CRD version management, allowing cluster admins to manage the installed Gateway API CRD on their cluster, but letting them know about risks.

Analyze:

• If our implementation of Gateway API properly ignores experimental CRDs
• If our implementation of Gateway API properly ignores experimental fields on standard CRDs (when experimental CRD is installed)
• If allowing experimental CRDs the cluster should be marked as unsupported

Validate (Some of the validations below are already part of Gateway API 1.5 

• Allow upgrading Gateway API CRD version from standard 1.x to 1.y
• Allow deploying experimental Gateway API CRDs over standard Gateway API CRDs
• Block downgrading Gateway API CRDs from version 1.y to 1.x
• Block moving back from experimental Gateway API CRDs to standard Gateway API CRDs
• Block deleting Gateway API CRDs.
• Alert when a non-supported version of Gateway API CRDs is being used (experimental or more updated)

Why is this important?

Customers are willing to use Gateway API, but eventually they want to use a different implementation from the one shipped by Red Hat, or even a parallel one. We have cases where customers want to use a partner Gateway API implementation that has more features, or cases where customers want to test newer features knowing that this may be unsupported.