Avoid trusting client-controlled areas of xenstore.

Avoid trusting client-controlled areas of xenstore.

Various parts of xenstore, specifically /local/GUEST/devices, are
writeable by the guest.  Information from these areas must be used
with care, to avoid the guest tricking qemu-dm into improperly using
its privileged access to dom0 resources.

To this end:
 * Variables and functions referring to client-controlled data have
   had `danger' added to their names.
 * There is a new sanitisation/checking arrangement for getting
   backend paths and information about the configuration of device
   backends, given the frontend information.  This is so that when
   qemu is providing a data path which is parallel to the PV
   frontend/backend arrangements, it only uses the configuration from
   a genuine backend which is really configured to serve qemu's own
   guest.
 * For information which should be read from or written to the `vm'
   tree, we obtain the guest's uuid from the hypervisor (the `label'
   as the hypercall interface calls it) rather than reading it from
   the guest-controlled areas of xenstore.
 * The `phantom vbd' feature is disabled.  It relies on
   guest-controlled xenstore areas indicating device paths on the
   guest.  We do not believe this feature is currently very relevant.
 * We _do_ allow the guest of a stubdom qemu to mess up the
   correspondence between pv backends and emulated devices, in the
   sense that we don't mind if the guest directs qemu to use a `wrong'
   frontend.

(cherry picked from commit 5d9302d372cf0a2951e3e0c61a5e08496de8aa2b)
Conflicts:
	qemu-xen.h