Support for an autopkgtest_backend: auto setting

User story

I would like to request this feature as an authenticated user, willing to use debian_pipeline-based workflows, that include enabled autopkgtest and autopkgtest for reverse dependencies tasks. I would like that those autopkgtest jobs run on the "minimal" backend supporting the restrictions found in the package's tests, i.e. lxc containers or qemu when isolation-container and isolation-machine are needed, respectively. For any other autopkgtest, running on the unshare backed should be enough. Taking the liberty of using openssh as example, the 1:10.0p1-1 version of that package includes four autopkgtests, all of them require isolation-container. And those autopkgtests are skipped in the current debusine.d.n upload-to-unstable's autopkgtest task, since it runs on the unshare by-default backend. With the proposed feature, I would like that such autopkgtest task runs on lxc (or qemu), making the autopkgtest task's outcome more meaningful.

Moreover, openssh's systemd reverse dependency includes an autopkgtest that requires isolation-machine: https://debusine.debian.net/debian/developers/work-request/85195/. So it would be awesome if, under the autopkgtest for reverse dependencies tasks, systemds runs on the qemu` backend.

As far as I understand, there are currently no clear plans about how a regular user could override the settings defined in the workflow template. I think that a dynamic autopkgtest backend definition mechanism would help, especially if several people could prepare updates for a package during the lifecycle of a debian release (maintenance team, sec team, LTS/ELTS team), so the debusine pipeline could provide consistent results at each release-based workflow.

Error handling

Implementation plan

Open questions

Notes

This issue description can be modified to integrate feedback from comments and from associated merge requests.