checks: Implement bespoke version parser

[Penwy]

Description

This replaces the usage of pkg_resources.parse_version with a version parser custom-made for OBS versioning.
It obeys to the semver 2.0.0 spec except for a stricter definition of pre-release versioning.

I also took the opportunity to cleanup messages relating to long-outdated versions of obs, and to add an "oudated beta" check that was suggested in comments.

The original includes a check for "caffeine" builds of OBS as an unofficial one. Having never seen one of those in years of support I would assume it isn't relevant anymore, but without clear knowledge on what those are, I preferred to leave it in. Clarifications on their current relevance is welcome.

Motivation and Context

pkg_resources.parse_version was only ever meant to be used for python packages and with setuptools >= 66.0 raises an error when called on a version that doesn't conform to python packages versioning rules. As an example, the simple inclusion of a -modified, quite frequent in obs versioning, is enough to break said rules, and as such, the analyzer.

While not currently breaking, as the analyzer is run on rather old python, the potential of breaking upon update is rather unwishable, and we should rely on a tool intended for the job, instead of using one in an unintended and unsupported way.

How Has This Been Tested?

Ran it with a bunch of logs plucked from the support server, observed no breaking, and proper reporting of version.

Types of changes

• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Fenrirthviti]

I also took the opportunity to cleanup messages relating to long-outdated versions of obs, and to add an "oudated beta" check that was suggested in comments.

this should probably just be a separate PR as it's unrelated, but, at the least should be its own commit.

[Penwy]

Do you mean the cleanup, or the new check?
And if both, both in separate commits?
(mb for the close, am tired)

[prgmitchell]

looks good to me, did some testing on my own as well with a collection of logs and saw no issues.

[RytoEX]

Probably fine.