* Disabled pyTooling/Actions/releaser composite on Ubuntu and use a container instead.
  The composite step is obviously broken on Ubuntu 20.04.

* pyTooling/Actions/releaser/composite updated to v0.4.6

* mingw-bundledlls apparently does not output MinGW-friendly filenames,
  so we cannot use it to bundle files into a directory differing from the
  executable's directory.

* make sure that all DLLs are packaged into the root directory even
  those for the pixbuf loaders

* mingw-bundledlls finds and copies transitive DLL dependencies.
* Like all external one-file sources, mingw-bundledlls has been copied into contrib/
  instead of adding a submodule.
  It's taken from here: https://github.com/mpreisler/mingw-bundledlls
* Packaging is more robust now if dependant DLLs are upgraded or if we
  decide to link in more statically.
  With the old scheme, we might also miss some DLL and break builds
  without even noticing it.

This is slightly less idiosyncratic than shipping a tarball of the installation root.
The pkg has been reported to be installable even via the graphic installer when providing
a password.
Or it can be installed via terminal with `sudo installer`.
So it no longer requires any manual dequarantining.

* replace actions/upload-artifact with pyTooling/Actions/releaser
* The release URL will never change:
  https://github.com/rhaberkorn/sciteco/releases/tag/nightly
* On the downside there is now a "nightly" tag in the repo that will
  be updated to HEAD whenever a nightly build runs - but other than that it does no harm.
* Compared with artifacts, the new method has several advantages:
  * No more nightly.link Github App required
  * We can add arbitrary files into releases and no longer have to ZIP everything.
    So you can now download the Debian packages separately, the Mac OS "package" is a tar.gz
    (instead of zipped tar).
    For the Windows packages not much changes, though.
  * Files get updated in the "Nightly Builds" release even when individual jobs in the
    nightly.yml workflow fail.
    With artefacts, the entire workflow must be successful.
  * Releases are not deleted after 90 days as opposed to artefacts.
    So when my workflow breaks next time, there will still be files to download
    for a long time.
 * As a downside, the file names in the release have to be uniform and must not contain
   versions, commit hashes and dates so that uploads replace old files instead of adding
   new ones.
   Some manual cleanup could still be necessary after large packaging changes.
   This could be worked around, by uploading everything first as artefacts and updating the
   release in a separate job, but is not worth the trouble IMHO.
 * Another disadvantage is that there will be no old nightly builds to download
   (although these were not easily downloadable for end users before).

* should fix Win32/Gtk packaging

* Gtk packaging is quite possibly still broken

As much as I like to support older systems, this will otherwise suddenly and unexpectedly break
CI and nightly builds in the near future...