add_drive: Introduce 'cachemode' parameter to control drive caching.

This commit adds an optional 'cachemode' parameter to the 'add_drive'
API to control caching.  This corresponds approximately to the
'-drive ...,cache=' parameter in qemu, but the choices are much more
restrictive, just 'writeback' or 'unsafe', for reasons outlined below.

The caching modes supported by recent QEMU are:

  writeback:
   - Reports data writes completed when data is present in the host
     page cache.
     Only safe provided guest correctly issues flush operations.

  writethrough:
   - Reports data writes completed only when each write has been
     flushed to disk.  Performance is reported as not good.

  none:
   - Uses O_DIRECT (avoids all interaction with host cache), but does
     not ensure every write is flushed to disk.
     Only safe provided guest correctly issues flush operations.

  directsync:
   - Uses O_DIRECT (avoids all interaction with host cache), and
     ensures every write has been flushed to disk.

  unsafe:
   - No special handling.

Since the libguestfs appliance kernel always issues flush operations
(eg. for filesystem journalling and for sync) the following modes can
be ignored: 'directsync', 'writethrough'.

That leaves 'writeback', 'none' and 'unsafe'.  However 'none' is both
a constant source of pain (RHBZ#994517), is inefficient because it
doesn't use the host cache, and does not give us any safety guarantees
over and above 'writeback'.  Therefore we should ignore 'none'.

This leaves 'writeback' (safe) and 'unsafe' (fast, useful for scratch
disks), which is what we implement in this patch.

Note that the previous behaviour was to use 'none' if possible, else
to use 'writeback'.  The new behaviour is to use 'writeback' only
which is (in safety terms) equivalent to 'none', and also faster and
less painful (RHBZ#994517).

This patch also allows you to specify a cache mode for network drives
which also previously defaulted to 'writeback'.

There is a considerable performance benefit to using unsafe (for
scratch disks only, of course).  The C API tests only use scratch
disks (since they are just tests, the final state of the disk doesn't
matter), and this decreases total run time from 202 seconds to 163
seconds, about 25% faster.
drives: Ensure all scratch drives use cachemode "unsafe".

They are _scratch_ drives so any data on them doesn't matter and can
be reconstructed in the event of a host system crash.
sparsify: Use cachemode "unsafe" for the overlay disk.
rescue: Use cachemode "unsafe" for the virt-rescue --scratch option.
drives: Don't need to call free_drive_servers since preceding code checks servers == NULL.
Version 1.23.20.