This commit adds the $PREFIX/bin/target_xen_vm_vmp daemon, which listens
for notifications from Xen on the VIRQ_DEBUGGER event channel that domains
have experienced debug exceptions... and forwards those notifications to
clients over unix domain sockets.  The thing is that only one process
can bind to the VIRQ_DEBUGGER event channel "port" at a time... so to run
multiple VMI programs, we need something like this, it seems.

This is now the *default* mode of operation for Xen targets.  If the user
does not provide the '-M' (--no-use-multiplexer) argument, and they attempt
to attach to a Xen domain -- either their VMI program will connect to a
running target_xen_vm_vmp daemon, or it will spawn one, and connect to it.
If they *do* supply -M (or via the XML SOAP server, noUseMultiplexer=true),
it will try to just connect directly to the VIRQ_DEBUGGER evtchn and
monopolize it.

Right now, the daemon does *not* try to figure out which domain is
experiencing the debug exception.  I don't know a guaranteed way to figure
this out, and thus the "safest" solution is to leave all that code where
it is, in some ways.  Obviously, this approach does wake up VMI processes
unnecessarily, but if that really becomes a problem, we can fix it).  It's
not a cost that worries me right off the bat.