Admin interface for Offline Volume Migration

This work will add an admin-only interface to manually invoke volume migration - "I want to move this volume to that specific backend". This is useful for manual tuning and scripting.

This initial version will be the simplest case - a detached volume with no snapshots. A later blueprint will handle cases of attached volumes and volumes with snapshots. Attaching/detaching during migration will not be allowed for now.

This will require:
1) Adding an RPC call to the scheduler, which will ensure that the volume can be moved to the new backend (in terms of volume_type, free space, etc.).
2) Adding an RPC cast to cinder-volume which will perform the migration. This will be the generic migration mechanism, which the scheduler can also call for other use cases in which it will choose the backend (for example, in retype_volume or evacuate_backend).
3) Expanding the driver interface to query the driver if it can perform the migration on its own. This is similar to clone_image() vs. copy_image_to_volume().

For #3, we also add here a driver-specific capabilities field to describe the backend's location. For example, the LVM driver can use this field to store the hostname of the server it is running on, and if the driver sees that the hostname of the target backend matches, it can migrate offline volumes using dd (bypassing iSCSI). Similarly, many controllers can migrate data between pools on the same array even for the attached case.
Note: This is NOT enabling backends to use features such as mirroring between arrays to perform the migration, where there must be orchestration between the source backend, target backend, and the hypervisor (for example, to pause I/Os or swap the backends). This is ONLY for the case where the migration can be done transparently by the driver/storage.