nodedev: Expose sysfs path of device

The name format is constructed by libvirt, it's not that clear to
get what the device's sysfs path should be. This exposes the device's
sysfs path by a new tag <path>.

Since the sysfspath is filled during enumerating the devices by
either udev or HAL. It's an output-only tag.
nodedev_udev: Refactor udevGetDeviceType

Checking if the "devtype" is NULL along with each "if" statements
is bad. It wastes the performance, and also not good for reading.
And also when the "devtype" is NULL, the logic is also not clear.

This reorgnizes the logic of with "if...else" and a bunch of "else if".

Other changes:
   * Change the function style.
   * Remove the useless debug statement.
   * Get rid of the goto
   * New helper udevDeviceHasProperty to simplify the logic for checking
     if a property is existing for the device.
   * Add comment to clarify "PCI devices don't set the DEVTYPE property"
   * s/sysfs path/sysfs name/, as udev_device_get_sysname returns the
     name instead of the full path. E.g. "sg0"
   * Refactor the comment for setting VIR_NODE_DEV_CAP_NET cap type
     a bit.
nodedev_udev: changes missed by commit 1aa0ba3cef
qemu: set QEMU_CAPS_DEVICE_VIDEO_PRIMARY cap flag in QMP detection

When qemu >= 1.20, it is safe to use -device for primary video
device as described in 4c993d8ab.
So, we are missing the cap flag in QMP capabilities detection, this
flag can be initialized safely in virQEMUCapsInitQMPBasic.
nodedev_udev: Enumerate scsi generic device

Since scsi generic device doesn't have DEVTYPE property set, the
only way to know if it's a  scsi generic device or not is to read
the "SUBSYSTEM" property.

The XML of the scsi generic device will be like:

<device>
  <name>scsi_generic_sg0</name>
  <path>/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0</path>
  <parent>scsi_0_0_0_0</parent>
  <capability type='scsi_generic'>
    <char>/dev/sg0</char>
  </capability>
</device>
nodedev_hal: Enumerate scsi generic device

The xml outputed by HAL backend for scsi generic device:

<device>
  <name>pci_8086_2922_scsi_host_scsi_device_lun0_scsi_generic</name>
  <path>/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/scsi_generic/sg0</path>
  <parent>pci_8086_2922_scsi_host_scsi_device_lun0</parent>
  <capability type='scsi_generic'>
    <char>/dev/sg0</char>
  </capability>
</device>
nodedev: Support SCSI_GENERIC cap flag for listAllNodeDevices
virsh: Support SCSI_GENERIC cap flag for nodedev-list

Document for nodedev-list is also updated.
spec: Enable KVM support on ARM

F20/rawhide has support for this.

From: Peter Robinson <pbrobinson@gmail.com>
qemu_migration: Move waiting for SPICE migration

Currently, we wait for SPICE to migrate in the very same loop where we
wait for qemu to migrate. This has a disadvantage of slowing seamless
migration down. One one hand, we should not kill the domain until all
SPICE data has been migrated.  On the other hand, there is no need to
wait in the very same loop and hence slowing down 'cont' on the
destination. For instance, if users are watching a movie, they can
experience the movie to be stopped for a couple of seconds, as
processors are not running nor on src nor on dst as libvirt waits for
SPICE to migrate. We should move the waiting phase to migration CONFIRM
phase.
qemu: Avoid leaking uri in qemuMigrationPrepareDirect
migration: Make erroring out on I/O error controllable by flag

Paolo Bonzini pointed out that it's actually possible to migrate a qemu
instance that was paused due to I/O error and it will be able to work on
the destination if the storage is accessible.

This patch introduces flag VIR_MIGRATE_ABORT_ON_ERROR that cancels the
migration in case an I/O error happens while it's being performed and
allows migration without this flag. This flag can be possibly used for
other error reasons that may be introduced in the future.
migration: Don't propagate VIR_MIGRATE_ABORT_ON_ERROR

This flag is meant for errors happening on the source of the migration
and isn't used on the destination. To allow better migration
compatibility, don't propagate it to the destination.