blockcopy: virDomainBlockCopy with XML destination, typed params
    
    This commit (finally) adds the virDomainBlockCopy API, with the
    intent that it will provide more power to the existing 'virsh
    blockcopy' command.
    
    'virsh blockcopy' was first added in Apr 2012 (v0.9.12), which
    corresponds to the upstream qemu 1.2 timeframe.  It was done as
    a hack on top of the existing virDomainBlockRebase() API call,
    for two reasons: 1) it was targetting a feature that landed first
    in downstream RHEL qemu, but had not stabilized in upstream qemu
    at the time (and indeed, 'drive-mirror' only landed upstream in
    qemu 1.3 with slight differences to the first RHEL attempt,
    and later gained further parameters like granularity and buf-size
    that are also worth exposing), and 2) extending an existing API
    allowed it to be backported without worrying about bumping .so
    versions.  A virDomainBlockCopy() API was proposed at that time
    [1], but we decided not to accept it into libvirt until after
    upstream qemu stabilized, and it ended up getting scrapped.
    Whether or not RHEL should have attempted adding a new feature
    without getting it upstream first is a debate that can be held
    another day; but enough time has now elapsed that we are ready to
    do the interface cleanly.
    
    [1] https://www.redhat.com/archives/libvir-list/2012-April/msg00768.html
    
    Delaying the creation of a clean API until now has also had a
    benefit: we've only recently learned of a few shortcomings in the
    original design: 1) it is unable to target a network destination
    (such as a gluster volume) because it hard-coded the assumption
    that the destination is a local file name.  Because of all the
    refactoring we've done to add virStorageSourcePtr, we are in a
    better position to declare an API that parses XML describing a
    host storage source as the copy destination, which was not
    possible had we implemented virDomainBlockCopy as it had been
    originally envisioned (although a network target will have to wait
    until a later libvirt release compared to the API addition to
    actually be implemented).  2) the design of using MiB/sec as the
    bandwidth throttle is rather coarse; qemu is actually tuned to
    bytes/second, and libvirt is preventing access to that level of
    detail.  A later patch will add flags to existing block job API
    that can request bytes/second instead of back-compat MiB/s, but as
    this is a new API, we can get it right to begin with.
    
    At least I had the foresight to create 'virsh blockcopy' as a
    separate command at the UI level (commit 1f06c00) rather than
    leaking the underlying API overload of virDomainBlockRebase onto
    shell users.
    
    A further note on the bandwidth option: virTypedParameters
    intentionally lacks unsigned long (since variable-width
    interaction between mixed 32- vs. 64-bit client/server setups is
    nasty), but we have to deal with the fact that we are interacting
    with existing older code that mistakenly chose unsigned long
    bandwidth at a point before we decided to prohibit it in all new
    API.  The typed parameter is therefore unsigned long long, but
    the implementation (in a later patch) will have to do overflow
    detection on 32-bit platforms, as well as capping the value to
    match the LLONG_MAX>>20 cap of the existing MiB/s interfaces.
    
    * include/libvirt/libvirt.h.in (virDomainBlockCopy): New API.
    (virDomainBlockJobType, virConnectDomainEventBlockJobStatus):
    Update related documentation.
    * src/libvirt.c (virDomainBlockCopy): Implement it.
    * src/libvirt_public.syms (LIBVIRT_1.2.8): Export it.
    * src/driver.h (_virDriver): New driver callback.
    
    Signed-off-by: Eric Blake <eblake@redhat.com>