Fix potential deadlock across fork() in QEMU driver

Fix potential deadlock across fork() in QEMU driver

https://bugzilla.redhat.com/show_bug.cgi?id=964358

The hook scripts used by virCommand must be careful wrt
accessing any mutexes that may have been held by other
threads in the parent process. With the recent refactoring
there are 2 potential flaws lurking, which will become real
deadlock bugs once the global QEMU driver lock is removed.

Remove use of the QEMU driver lock from the hook function
by passing in the 'virQEMUDriverConfigPtr' instance directly.

Add functions to the virSecurityManager to be invoked before
and after fork, to ensure the mutex is held by the current
thread. This allows it to be safely used in the hook script
in the child process.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 61b52d2e3813cc8c9ff3ab67f232bd0c65f7318d)

Conflicts:
	src/libvirt_private.syms - context
	src/qemu/qemu_process.c - no backport of qemud_driver struct rename
	src/security/security_manager.c - no backport of making the security driver self-locking; just expose the interface