Depending on strict versions of libraries to build the compiler results in packaging issues

[cameel]

Currently our build system requires specific versions of several smaller libraries we depend on, namely:

• fmtlib 9.1.0
• nlohmann-json 3.11.3
• range-v3 0.12.0

We only ever build and test with those specific versions and update them only sporadically. This means that we won't easily detect issues stemming from someone building with different versions. It's only in this release that we added CMake options that allow using versions available in the system (#14860) and even then the options are undocumented and not officially supported.

This has recently became an issue because Homebrew started enforcing a policy that prevents us from downloading those dependencies at build time (Homebrew/homebrew-core#172338). Since we don't include them in the source archive, the only choice we had for now was to start relying on versions provided by Homebrew, which are different than those expect. We need to address the issue more robustly:

• If we decide that specific versions are a must-have, we should start including them in the source archive and always build with them.
  • Perhaps this is also the moment to switch to having them as submodules in the repo, as proposed long ago in External dependencies: json-cpp, fmtlib, ranges-v3, intx, z3, cvc4 #8860.
• Alternatively, we could just document the supported range of versions, which would make building with the ones provided by Homebrew just fine.
  • For that to be safe we'd need to also start testing with those versions in CI (related: CI run with minimum versions of dependencies #15136).

[cameel]

Decision from the call today: we got with submodules and we'll include source of dependencies in the source archive.

This way the problem in Homebrew won't repeat in 0.8.27. For 0.8.26 we should ask Homebrew maintainers to allow us to use HOMEBREW_ALLOW_FETCHCONTENT just for that version.