Pin GAP_jll and GAP_lib_jll versions more tightly?

[fingolfin]

Apparently when I updated GAP_jll and GAP_lib_jll last night, this immediately was available in GAP.jl and hence Oscar.jl, without any changes there; see e.g. oscar-system/Oscar.jl#6195.

On the one hand, that was nice, as it resulted in a fix there "for free".

On the other hand, in other situations this could be undesirable.

Should we perhaps have a tighter version restriction on those two JLLs, so we stay in control when updates reach users?

CC @lgoettgens @ThomasBreuer

[lgoettgens]

I think that we should allow patch releases of the jll to arrive immediately, as otherwise this gets tedious quite fast (like with GAP_pkg_juliainterface_jll).
What would be a workable solution for me is to map the patch part of the gap version to the minor part of the GAP_jll, e.g. 4.16.1 maps to something like 400.160100.0.

But honestly, we don't rebuild GAP_jll and GAP_lib_jll nearly as often as eg GAP_pkg_juliainterface_jll. So even doing a = compat wouldn't be too much of extra work.

So overall, I would be happy with a = compat