Don't auto import domain's storage volume

This is part of a big epic/effort to introduce Import/Export capabilities in Boxes.

What this MR does is that it doesn't perform copies of disks into Boxes' images/ folder automatically. This way, once you connect to a libvirt broker or you select a disk file (qcow2, vmdk, vdi, etc...), Boxes won't try to copy the disk into our prefix but instead it allows you to run the disk from wherever it is.

This could eventually introduce a regression because you are not always allowed to "Clone" a VM in a broker that you don't control (don't have permission). This way, we replace the "Clone" functionality with "Import".

"Import" clones the VM's XML and copies the storage_volume (disk) into the Boxes internal storage location.

UI/UX

To make it easy for users to tell whether a VM is stored locally (in ~/.../data/gnome-boxes/images/), this MR classifies all VMs that are not in this prefix as "Remote" (they show in the "Remote" view when clicking in the stack switcher). These can be really remote when the libvirt broker which they belong is in another machine. But some of them are just disk files available in other locations in the users filesystem. In other words, a "Remote" VM is a VM that you cannot Clone but you can Import. It is a VM that isn't stored internally into Boxes.

The two VMs in the screenshot above are backed by qcow2 files stored in independent locations in my filesystem. Note that they are visible in the "Remote" tab, and they have "Import" in the actions-popover instead of "Clone".

Once they are Imported, they are copied/clone into new VMs which are Local (internal to Boxes) and can be cloned normally.

@jimmac: are you satisfied with the classification between Local/Remote in this context? Could we alternatively rename "Remote" or introduce a new tab?

And also, are you satisfied with the exchange between Clone and Import based on whether the VM is stored internally or has a custom location.