Only deploy the package files from the master branch

See merge request !1

There are a couple of relevant warnings from shellcheck:

> In build.sh line 62:
> apt-get source ${package}
> SC2248: Prefer double quoting even when variables don't contain special characters.
> [...]
> In build.sh line 66:
> tar xf "${package}"_*.debian.tar.xz -C "${package}"-"${version}/"
> SC2140: Word is of the form "A"B"C" (B indicated). Did you mean "ABC" or "A\"B\"C"?

Instead of continuing with the next steps, abort the script on a
failed or partial download of the source code.

Document the build script to make it easier to understand what is going on in the various sections.

The radsecproxy project moved it man pakges from section 1 to
section 8 after Debian buster shipped.

This caused updated versions to fail to build since Debian Buster
expected the man pages in the old location.

Document this and note that the workaround is only necessary for
Debian Buster.

Here the Debian package name happens to overlap with the upstream
project name, but mixing them makes the meaning of `${package}` a bit
confusing.

Instead of trying to add the "deb-src" entries to sources.list for the
current distro, we can look at the existing file to determine the
lines that we should add.

This is simpler and more reliable when Debian restructures their
repositories.

Move the code for generating the changelog file to a single location
and build it in two steps.

In general it is better to specify our exact dependencies instead of
relying on recommended packages to install them.

When we install our build dependencies, we get some warnings from
debconf:

> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.)
> debconf: falling back to frontend: Readline

Fix those by specifying that we are running non-interactively.

Instead of repeating the job for multiple distros, we can use the new
`matrix` functionality to instantiate the job multiple times.

Here we use this to build the package for all supported distributions.

Instead of listing each distribution, check what distributions we have
packages for in the output directory and upload those.

We are going to restructure the deployment to automatically detect the
distros. This is easier to do from a shell script, so move the
commands to their own shell script.

When we build the packages locally, we end up filling our project
directory with all the temporary files that are generated as part of
the build.

Avoid this by switching to a temporary working directory before
building the packages.

Instead of repeating the commands to copy the Debian package files in
each build job, we can add the copy to `build.sh`.

This also makes it easier to run the build locally, and will make it
simpler to build the packages from a temporary working directory.

GitLab CI already runs all jobs in Docker. Running new Docker commands
requires us to use Docker-in-Docker.

In this case, this is unnecessary and unnecessarily complicated. We
can simply let GitLab CI run the required containers for us.

Instead of starting a new Docker container to build the package

Instead of having one output directory for each target distro, have a
common output directory with a subdirectory for each distro.

This will make it possible to restructure the project to make it
easier to add additional distributions.

Instead of repeating the build dependencies in both Dockerfile-files,
let us install them from `build.sh`.

To make it easier to test and review changes, run the build commands
for all branches, but avoid deploying the generated package files to
apt.uninett.no.