Retool Kong version handling post-3.x

[rainest]

#2932 added a compatibility layer between Kong/go-kong#206 and blang/semver, which is what the KIC code expects and uses throughout its version-dependent behavior systems. go-kong now uses a forked semver with a non-standard Revision field to hold the additional Enterprise patch version. This compatibility layer is a bit silly, and we should move towards having a less messy situation.

• https://github.com/Kong/kubernetes-ingress-controller/blob/c62a3610d6d8c9cd509e99932675f5576177db8b/internal/versions/versions.go has overlap with the functionality provided by the go-kong Version type. We should port this functionality into go-kong. go-kong does have functions to return Major/Minor/Patch individually but not in progressing groups. The MajorMinorOnly() and MajorMinorPatchOnly() functions are useful for behavior comparisons, since we often do not care about pre-release or patch information (typically we only add functionality after Kong adds it, and effectively all versions of a given minor release will support a feature--we're not going to go back and test against older pre-release builds that lack it). Full() will include the Revision also after; we may optionally add a new MajorMinorPatchPrereleaseOnly() (or MajorMinorPatchRevisionOnly()? I'm not sure of the precedence order between Revision and Prerelease), but as of yet have no use for it, so it'd only be for completeness.
• KIC uses upstream semver throughout. We need to either convert these instances to our new fork or add a go-kong function to return a blang/semver.Version from a Kong/semver.Version. The go-kong Version type currently lacks functions to return a complete Version (which we want), but the above point will handle this.
• The previous version string scraping was precarious, as is the new one. We probably should not rely on string munching to determine version and capability information, as it's annoying to implement in the best case. We should consider adding gateway functionality to provide structured data instead, so that instead of 3.0.0, 3.0.0.0, 2.8.1, and 2.8.1.0-enterprise-edition we have something like {"Major": 3, "Minor": 0, "Patch": 0, "Revision": 0, "Enterprise": true} directly from the admin API. Future changes should then be new fields and thus backwards-compatible--if our libraries are not updated to recognize the new fields, we don't care, because we continue filling the old ones in the same way, rather than needing to add more complexity to the string parser. However, this would only be available in newer versions, so we'd be stuck with the string parser for older versions (but would not need to update it further).

[pmalek]

Related: Kong/go-kong#212

[pmalek]

@mflendrich You volunteer yourself to groom this 🪄