+ caused deadlocks on program exit, as functions called from signal handler were not async-signal-safe (see: man signal-safety). Amongst others, malloc and pthread_join are not safe.
+ OS will cleanup our threads and db queue anyway
+ saving defined user params on exit is no longer necessary as we save them on every edit action
+ because of all the above, we can safely leave signal handling and cleanup to standard OS behavior on Linux

+ there is a lock introduced in "Add global parser synchronous access mutex", but still draw3 segfaults on init
+ segfaults are not reproducible using valgrind, and happen in AddPar, where curr points to a badly initialized structure
+ altogether this looks very much like a multithreading issue
+ so introduce a recursive_lock, locking every single function in libparnt
+ this is extremely ugly, but it works and it doesn't slow down program start remarkably
+ a proper fix would be removing all the libparnt code and writing a new, simple, parser for szarp.cfg

+ follow-up of "fixed deadlock in defined initialization"
+ previous fix fixed the deadlock in one case, but not in the general case, as unfortunately there are other call-traces that lead to the deadlock
+ this fixes a sequence, where thread 1 calls UDIM::AddUserDef (acquires mutex), which calls UDIC::AddUserDef (acquires m_lock); while thread 2 calls PCIC::GetConfig (acquires m_lock), which calls UDIC::AddConfig, which calls UDIM::PopConfig (acquires mutex)
+ the general design flaw is that UDIM can call UDIC and vice versa. This is wrong and especially bug-prone when using locks.
+ this fix should fix the general case. The design flaw remains to be fixed, but now whenever UDIM calls UDIC, it does so without holding mutex (fixed both places in code where I found such a situation). So both locks are held only on the path from UDIC to UDIM and not vice versa.

+ launch query executor as the last step of OnInit
+ this fixes a segfault when QueryExecutor tries to SetProberAddress while OnInit didn't finish loading configurations
+ probably this worked previously only because configurations loaded fast enough

+ if we import a set in draw3 (from .xsd file), defcfg won't set _configId in imported params, leaving it uninitialized and leading to strange errors
+ initialize _configId to invalid value, so at worst it will fail in a more comprehensible way
+ we cannot throw from GetConfigId because of the "Caught unhandled unknown exception; terminating" wx behaviour which hides the place in code from which an exception is thrown. Overriding OnUnhandledException and OnExceptionInMainLoop in szapp (and e.g. calling abort, terminate from there) has no effect.
+ introduced a workaround in a completely different part of code than importing set, as the bug in importing set would be hard to find