Use Docker for Ubuntu x64 job

[neildhar]

We currently use GitHub's runners to build LLVM binaries, which are subject to the toolchains that GitHub preinstalls on them and the GitHub's deprecation schedule. This causes problems when we want to build binaries for distribution, because we cannot maintain close control of binary compatibility.

For example, bumping from GitHub's 20.04 runner to the 22.04 runner also bumped the minimum required libstdc++ version, breaking binary compatibility on systems with older toolchains. This is made trickier by the fact that the runners come with multiple versions of GCC (including GCC 12 in this case) and Clang always picks the newest libstdc++ available on the host.

Docker allows us to maintain fine control over the environment in which binaries are produced. We can continue running old versions of containers indefinitely and pin the exact toolchain version that is used to build.

LLVM maintains compatibility with much older compilers, so we could pick even older images than 22.04 and potentially eliminate the need to maintain multiple binary distributions for Linux. But this seems like a good first step.

New contributor declaration

• I am not making a trivial change, such as fixing a typo in a comment.

• I have written a PR description following these
  rules.

• I have run pre-commit run --from-ref origin/main --to-ref HEAD.

• Select one of the following.

  • I have added tests.
    • /test for lit tests
    • /unittest for C++ tests
    • /python/test for end-to-end tests
  • This PR does not need a test because it is a CI change.

• Select one of the following.

  • I have not added any lit tests.
  • The lit tests I have added follow these best practices,
    including the "tests should be minimal" section. (Usually running Python code
    and using the instructions it generates is not minimal.)

[ThomasRaoux]

that kins of make sense but won't the problem still be there based on the toolschain version picked in the docker?
If you need controlled dependencies building from source sounds like a better flow for you? The option should be there and easy to use in the cmake file, did you try that?

[neildhar]

won't the problem still be there based on the toolschain version picked in the docker

My goal with this change is not to eliminate binary compatibility issues with systems using older toolchains, but rather to:

1. Keep control of the environment so that it doesn't change and break existing usage. For example, with this change, the build would no longer be subject to GitHub's deprecation schedule for runners.
2. Improve compatibility by dropping the GCC toolset version from 12 to 11.

building from source sounds like a better flow for you? The option should be there and easy to use in the cmake file, did you try that?

I was able to build from source, but I think there's value in having the simpler (and much faster) version of the build work for as many cases as possible, especially as someone new to Triton.

[neildhar]

Closing since #8405 would produce binaries that are compatible with a superset of the systems handled here, in a controlled way.