Build wheels on test-infra machines

[NicolasHug]

This PR moves our linux wheel building process from the default GA machines to the pytorch infra machine from test-infra. Testing is unchanged: we download the built wheels artifacts, install the wheels and run the tests on separate machines.

This moves ensures that torchcodec is built on the exact same infra as pytorch.

Additionally, this PR adds a renaming step for the wheels: we rename the wheels from "linux_x86_64.whl" to "manylinux_2_17_x86_64.manylinux2014_x86_64.whl" so that they can be properly uploaded on PyPI. In general that renaming step should be done with tools like auditwheel. We don't do that and instead do the renaming ourselves. There are multiple reasons to that:

• auditwheel would by default try to vendor every single dynamic library that we depend on. That includes all of the ffmpeg libraries. We don't want to ship any ffmpeg library because we want users to be able to install their own. Using auditwheel would force us to use the following command, whose complexity hopefully speaks for itself

auditwheel repair --plat manylinux_2_17_x86_64 dist/* --exclude libtorch.so --exclude libtorch_cpu.so --exclude libc10.so --exclude libavutil.so.56 --exclude libavcodec.so.58 --exclude libavformat.so.58 --exclude libavdevice.so.58 --exclude libavfilter.so.7 --exclude libavutil.so.57 --exclude libavcodec.so.59 --exclude libavformat.so.59 --exclude libavdevice.so.59 --exclude libavfilter.so.8 --exclude libavutil.so.58 --exclude libavcodec.so.60 --exclude libavformat.so.60 --exclude libavdevice.so.60 --exclude libavfilter.so.9 --exclude libavutil.so.59 --exclude libavcodec.so.61 --exclude libavformat.so.61 --exclude libavdevice.so.61 --exclude libavfilter.so.10

• pytorch doesn't use auditwheel itself, it just does a hard rename like we do here
• The point of auditwheel is to ensure that the wheel doesn't depend on libraries or version symbols that are too new. We already ensure that ourselves with our custom check_glibcxx.py check.

[NicolasHug]

We move from 3.8-3.12 to just 3.9.

• We can't use 3.8 anymore because test-infra doesn't support it.
• on top of that, we can only use 3.9 here (for now) because by default, test-infra will only generate job on 3.9 on PRs. Generating job for all python versions can be done by labeling the PR with ciflow/binaries/all (I will eventually document this). What we should be doing here is letting this install-and-test job rely on the exact same python versions that were generated by the generate-matrix job. I haven't found a way to do that yet, but this should be doable, possibly requirement extensions to test-infra.

For now though, this is OK. We will still be able to checks all necessary python version when we push a new release.

[NicolasHug]

These are the same sanity checks that we used to run before, with the addition of the wheel renaming at the end.