Build a deb package for Arti (download dependencies while building)

This MR adds support for building an Arti deb package. Dependencies are downloaded while building (i.e. like cargo does normally).

Features

• Cargo.lock is honored
• Cross compilation is supported out-of-the-box (see below)
• Tests are run unless cross compiling (but see below for cross-running tests)
• Including other binaries in the package (e.g., idk, arti-testing for testing purposes) is very easy
• Manpages, generated using clap_mangen and then improved by hand, are included
• Documentation hand-picked from doc/
• Support for non-default profiles, mainly for debugging/testing purposes (see below)

Default and non-default build profiles

By default, Arti is built with the default features and using the release profile (but keeping the debug info so that dpkg can separate it into a dbgsym package). However, mainly for debugging and testing purposes, I sneaked in some code to allow building Arti using the debug profile and/or full features. For a debug build, use the debug deb build profile (e.g. sbuild --profiles=debug). For a build with full features (i.e. --features full), use the full deb build profile (e.g. sbuild --profiles=full).

Cross compilation

Since TPO's build infra runs on x86_64 machines, cross compilation is supported OOTB to provide packages for other arches (cough cough... me... cough cough...). I tested cross-compilation using two of the supported procedures at https://wiki.debian.org/CrossCompiling, namely, sbuild

# dpkg --add-architecture $ARCH inside the schroot, then
sbuild --host $ARCH

and dpkg-buildpackage inside a Docker/Podman container (not necessary, but I didn't want to install tons of otherwise useless dependencies on my machine)

dpkg --add-architecture $ARCH
apt-get install build-essential crossbuild-essential-$ARCH
apt-get build-dep -a$ARCH .
CONFIG_SITE=/etc/dpkg-cross/cross-config.$ARCH  DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -a$ARCH -Pcross,nocheck

Cross configurations tested to build are arm64, amd64 -> arm64, amd64, i386, armhf, ppc64el (arm64 -> arm64 and amd64->amd64 are just native builds). riscv64 and mips64el fail to cross build because of missing or conflicting dependencies (this may be temporary, I'm not sure), i.e. presumably not because of Arti or the packaging. armel and s390x do not build even natively for at least these reasons:

• coarsetime uses 64-bit atomics which are not supported on armel, thus arti doesn't build for that platform. If you are interested in adding support for armel, I think I know how to fix this upstream (I did it before for another crate, didn't try with this one specifically)
• merlin does not support big-endian targets, thus arti doesn't build on s390x and the likes. However, the upstream developer has this to say: This crate doesn't support big-endian targets, since I didn't have one to test correctness on. If you're seeing this message, please file an issue!

Currently tests must be disabled to run cross builds (sbuilds does this by default, for dpkg-buildpackage see above). One option to perform tests while cross compiling is to add an extra cross-test build profile which depends on qemu and emulate the tests. I've cross-ran rust test before so I think I know how to do this, but perhaps it is not worth it?

Note: some cross builds currently fail on Debian unstable because of missing dependencies, but this is likely only temporary because whatever I said builds does build on Debian testing.

Notes/TODOs

• This MR is currently based off the arti-v1.2.6 tag so I could build that exact version. It will be rebased before merge or after new releases.
• d/changelog and d/control contain my name, and the debian revision of the package is 1tpo1 to distinguish it from a package that could be uploaded to Debian main. You will likely want to change this.
• There is no service file yet, which is the reason why arti-example-config.toml is in /usr/share/doc/arti rather than in /etc/arti (it would be pointless to have a system configuration file at this stage). I will open a thread specifically for this as it requires some discussion.
• It is not too hard to generate manpages at build time using clap_mangen, but the results can be suboptimal (which is why I modified them by hand). If you are happy enough with them nonetheless I can easily integrate them into the deb package (that is, after you generate them).
• clap_complete may be used to generate shell completions in a similar fashion
• If you want me to add more docs (but also whatever else comes to your mind) feel free to ask