We should never use db_handle_ without ensuring that the db is
locked (which infact is not the case here).

Behind the curtains pthread_cleanup_pop is a destructor and
pthread_cancel causes an exception (via a signal).

This means that if you try to cancel a job while that job is in the
process of ending, then you risk an unfixable crash.  We want to make
this less likely and move the CleanupCall outside the destructor.

Note that this is just bandaid and not a real fix.  There are still
multiple other destructors and pthread_cleanup_calls inside the call
stack, so this can always cause a crash.

The only way to prevent these crashes (even if they are very unlikely)
is to rewrite everything to not rely on pthread_cancel and instead use
some other mechanism for cancelation.   This is very hard as we also
have to be able to cancel stuff like write/read/sleep/etc.

We would have to rewrite them with non blocking alternatives to have a
chance of achieving this (or by using the TIMEOUT signal, but that has
other issues ~> signal (un)safety).

This function is only called when everything is stopped, so we should
not assert that we are the owner here ...

Now we get some line numbers in the assertion which should help us
figuring out the problem in case no backtrace is available.

We used to supply LockDb/UnlockDb with pretty useless line numbers as
they were always the same regardless of which DbLocker it actually
was.  Now we use the line information of the creation of the DbLocker.

The removed macros were just used to inject line information into the
db calls.  As this can now just be done by using source_location we
can remove them and just use proper functions.

This way the autodetection works correctly.  For some reason
check_cxx_source_compiles() uses C++20.  Maybe the check is performed
too early ?