Bump boost, gcc, clang for non-windows builds and add CI job with these versions

[clonker]

Use explicit .operator==() calls to avoid infinite recursion in rational-to-integer comparisons caused by symmetric operator overload resolution bug.

Fixes #16084.

We might potentially want to add a CI job as outlined in #15136 to this PR. Or do it separately.

Adds a CI job that tests on 22.04 which falls into the gcc/boost version category that is problematic. The shipped glibc is too old for current evmone releases, therefore it skips smt and semantic tests.

[cameel]

This is testing the wrong CMake version. 3.21.3 is the minimum only on Windows. We support CMake down to 3.13 on Linux. We should also remove the remains of Ubuntu 22.04, which seems to be no longer used after this change.

Other than that mostly minor stuff.

[cameel]

Looks like we no longer need the base_ubuntu2204 definitions and the ubuntu-2204-docker-image Docker image. We should remove these and also its Dockerfile.

[cameel]

We could also replace it with a variant of the 2404 image with the lowest supported Clang and GCC pre-installed (by basically integrating your script into its Dockerfile). This way we would not have to install them every time the job runs.

Otherwise we should use save_cache/restore_cache to cache them, but that wouldn't be easy because they throw their stuff around the filesystem.

This is probably better done in a separate PR, because it will result in the images being rebuilt.

[clonker]

Yep I agree. Otherwise this job is prone to breakage whenever the images are updated. Removing the dockerfile itself would trigger building the images as well right? So let's bundle that with a follow up.

[cameel]

Sounds good.

[cameel]

A few more nitpicks, though they are minor and I'm already marking as approved.

[cameel]

Please also add an entry for 1.83 to the list above.

[clonker]

fair enough. not sure if this list is really needed in the end but it also doesn't hurt :)

[cameel]

It is useful to know what the constraints are for being able to use a particular version. Especially when some of them won't necessarily make a build fail. I started listing them after the experience of rebuilding ancient compiler versions for macOS, which would have been much easier if we had the foresight to add such notes on updates. This info is trivial to obtain when you update but disproportionately hard when you have to figure it out by trial and error later.

I guess the older entries become less relevant with time and could be gradually removed, but I also don't see much downside to keeping them. In either case the latest one is the most useful and should be added.

[cameel]

I mean, I guess it should be an entry for 1.75, which fixed the bug.

Though 1.83 should be there as well. If we're jumping to 1.83 just because of Trixie and there is no hard blocker to going lower if it turns out we need to for some reason, that's useful information too.

[cameel]

I think the last thing left is the question about why we're bumping only to GCC 13.3 and not 14+.

[clonker]

I think the last thing left is the question about why we're bumping only to GCC 13.3 and not 14+.

Same reason as for clang: it is the version that comes with Ubuntu 24.04.