Do not pollute environment of calling process, otherwise all VMs started
from Qubes Manager afterwards will get QREXEC_STARTUP_NOWAIT, which
will cause wait_for_session not working.
Alway start stubdom guid, then if guiagent_installed set - start the
target one and when connects, kill stubdom one. This allow the user to
see startup messages so prevent the impression of hang VM.
Note 1: this doesn't work when VM disables SVGA output (just after
windows boot splash screen).
Note 2: gui-daemon sometimes hangs after receiving SIGTERM (libvchan_wait
during libvchan_close). This looks to be stubdom gui agent problem.
Using class method allow the users (Qubes Manager at least) to check
for compatibility without having any particular VM instance - useful
while creating the VM.
Any HVM (which isn't already template-based) can be a template for
another HVM. For now do not allow simultaneous run of template and its
VM (this assumption simplify the implementation, as no root-cow.img is
needed).
HVM can set some xenstore entries (in qubes-tools/ subtree) to pass
informations about installed tools to dom0. qubes.NotifyTools service
triggers update of VM properties (like qrexec_installed).
This way, after installation of Qubes Windows Tools, the user doesn't need
to change any VM settings to use the tools.
If not marked as installed, start it in background - waiting for
possible Qubes Tools installation. If that happens, make it possible to
tell the dom0 about that fact.
