Otherwise all other attempts to acquire named locks are blocked. It should
be ok because references are not invalidated when inserting/accessing
elements of an `std::unique_map`. When cleaning locks up elements are
erased, though. Hence an additional cleanup lock is required to prevent
acquiring a named lock which has already been cleaned up.
Simply adding `--sign` to the `makepkg` flags doesn't work because it would
require setting up GPG within the chroot environment (of `makechrootpkg`).
When debugging it is anyways annoying that `makepkg` sends the `gpg` output
to `/dev/null`. This way the logs are preserved.
* Can not use a normal mutex because we don't want to tie the resources to
a specific thread (and instead e.g. to a build action which might not be
executed by a single thread)
* A semaphore would do that but libstdc++ only supports it as of GCC 11 and
besides it wouldn't distinguish between shared and exclusive locking
Martchus