flatpak, packagekit: fix threaded deadlock in dlopen/gmodule

the use of threads caused a deadlock between appstream's lazy
initialization code running in one thread and flatpak's init running in
another. the two would try to dlopen further libraries of which some
will gmodule load plugins. the problem appears to then be that the
threads can end up locked between two mutexes (the dlopen one and the
gmodule one).

instead use a safer albeit less efficient means of init: queue the init
into the event loop. this uses a two stage queue which looks a bit funny
but seems to have much the same performance characteristics as the
threading did.

BUG: 481993
(cherry picked from commit bdee5a19)