Add IsPatch/Minor/Major/K0sUpgrade functions

[kke]

Adds functions for checking if upgrading to another version would be a patch, minor, major or k0s upgrade.

[twz123]

Smart-ass question: If both v and b are nil, this function returns false, albeit v == b. This somehow breaks the transitive relationship that the method's name implies (i.e. I think it's reasonable to assume that a.segmentEqual(b) is true if a == b). Should we support the receiver being nil here in the first place? The existing methods don't do it, if I'm not mistaken.

Same for the other new methods.

[kke]

🤔 Hmmmmmm.

Maybe these should have an error return. Neither true or false is "safe".

Maybe there should be something like:

type Upgrade struct {
  a, b *Version
}

func NewUpgrade(a, b *Version) (Upgrade, error) {
   ....
}

u, err := version.NewUpgrade(this, that)
if err ..... { }

if u.IsMinor() { .... }

[twz123]

That would be a good approach if there's the need to explicitly deal with nil pointers on each invocation. However, I would be okay with panicking if the receiver or the argument is nil. Why would a pointer to a Version be nil in real code? I can only come up with these reasons:

1. A variable was forgotten to be initialized and its zero value is used
2. A returned non-nil error was ignored when parsing a version string or calling another function that returns (*Version, error).
3. The version is a piece of information that might or might not be available at runtime.

The first two are bugs. The third also somehow indicates that it should be up to the caller to deal with the situation. The methods here have no way of knowing what makes sense to assume in the absence of version information. The caller should decide.

In any case, I'd argue that calling the methods with nil pointers is a programmer's error that warrants a panic not to hide bugs, and not something that needs to be dealt with by this method. When in doubt, callers can still choose to do the nil checks themselves. They have more knowledge about whether one of the pointers can be nil at call time. I suppose it will turn out that in practice these nil checks are almost always unnecessary.