Support parsing of Git release-candidate versions
In some places, we need to check whether Git supports a certain feature or not. As Git doesn't usually provide a direct way to test for a feature, we instead use the version number as a proxy. This works just fine for normal releases by just parsing the semantic version number as a tuple of integers in the format "major.minor.patch". But we do not correctly cope with release candidates like "2.28.0.rc0", returning an error.
Fix this by expecting an optional fourth touple, setting a flag inside the version structure that says that it's a release candidate. Furthermore, we also need to extend the version comparison code: a release candidate is always older than its respective release.
Note that we do not parse the actual release candidate number. As numbering is zero-indexed, we cannot simply use "0" as a placeholder for a non-release-candidate, and everything else will require additional logic. As it's quite unlikely that we'll ever need to verify whether a given version is a specific release candidate (new features aren't usually introduced in between rc's and they shouldn't run in production anyway), adding this additional logic doesn't seem to be worth it at all.
This fixes broken tests and also broken production code whenever running git rc's.