turnip/ci: add a750 vk & gl (using zink) jobs

@mupuf got two new Qualcomm HDK boards (a740 and a750) as a pre-cursor to a wider deployment at the same hardware lab as most of the RADV DUTs. For this reason, we decided to re-use the same infrastructure as RADV and simply add support for fastboot to CI-Tron. This would reduce our maintenance and development burden by having all DUTs usable using the same system, including outside of Mesa.

For Mesa, our plan was to replicate what we did with RADV and simply have our boot2container initrd run the existing debian/arm64_test image instead of the debian/x86_64-test-* images. This however did not work because the arm64 images were in fact x86_64 images containing a debian system that has all the dependencies to start the job on a DUT, along with a copy of the lava rootfs + extra software added on top... In other words, contrary to the debian/x86_64-test-* images, this one is unusable outside of a bare-metal CI farm.

This left us with the following options:

1. Create a brand new container image that is usable by CI-Tron (and others)
2. Deploy a separate CI farm at the hardware lab that is already supported for freedreno testing by Mesa CI (LAVA or bare-metal)

The former option is bad because it adds to the current duplication problem (remember, the debian/arm64_test image contains a copy of the LAVA rootfs), and adds yet another place to modify when changing the test environment (updating llvm,...). Given how big these images are and how many times they got regenerated this year alone (~90 times), we definitely don't want to add to the problem.

The latter option is out of the question for us for the same reasons it was out of the question for RADV: We need to expose our DUTs to more than just Mesa and thus require as little boilerplate code as possible in every project (we are still working on getting the it to ~0 LoC over what it would take to run in the cloud runners), both LAVA/bare-metal would not comply with the security policy of our hardware lab (DUTs cannot have Internet access), and we want to be able to focus on what the developers need and not have to wonder if the hardware setup got changed by accident by the lab technicians (CI-Tron takes care of that for us).

Given that we really want to add support for newer Adreno GPUs, we took a deep dive into Mesa CI to identify the capabilities of every CI farm, how they are currently used, assessed strengths and weaknesses of the current implementation, then proposed a plan that would allow us to improve Mesa CI for everyone, including our problem at hand. Since the report is a little long, we decided to create a separate issue for it.

Satisfied with the fact that going with the first option would could be the first step to a Mesa-CI-wide improvement plan, we decided to go with that in this MR, along with the following modifications:

• Renaming the debian/arm*_test images into debian/baremetal_arm*_test
• Refactor to remove a surprising dependency of test images on build images
• Turn the x86_64 test images into a multi-arch version to share the same test environment between different architectures
• Move the b2c parameters to an extra URL endpoint to shorten the kernel cmdline to workaround a limitation of the Android bootloader

With that out of the way, we can add a VK CTS job (a750_vk) and a GL+GLES CTS job (zink-tu-a750) 🙌