This adds two new options: --format specifies the format of the
input disk, and --output-format specified the format of the output
disk.

Requiring the format of the output disk seems a bit strange at first:
after all, this is the disk that the virt-resize user has to create.
However it is needed because we sometimes reopen this disk, after
copying data over the first sector, and in theory a raw-format guest
could write a qcow2 header here and have it copied to the output
disk, which we would subsequently reopen.

The format parameter is taken from libvirt if available, else
the user should supply the '--format' parameter (eg. for local
disk files).

Sys::Guestfs::Lib is changed in two ways: firstly we take the format
string from libvirt and pass it to add_drive_opts.  Secondly we allow
an extra format =>  parameter to open_guest which allows the
format to be specified for disk images.

All the tools are changed to add an extra --format parameter allowing
the format to be specified for direct disk images.

For command line disk images, specify the format using --format option
in the same way as for guestfish.

For libvirt guests, the disk format is copied from libvirt (if
libvirt knows it).

For command line disk images, you can use --format to override
format auto-detection.

This large commit changes the generator so that optional arguments
can be supported for functions.

The model for arguments (known as the "style") is changed from
(ret, args) to (ret, args, optargs) where optargs is a more limited
list of arguments.

One function has been added which takes optional arguments, it is
"add-drive-opts", modelled as:

  (RErr, [String "filename"], #required
         [Bool "readonly"; String "format"; String "iface"]) #optional

Note that this function is processed in the library (does not go over
the RPC protocol to the daemon).  This has allowed us to simplify
the current implementation by omitting changes related to RPC or the
daemon, although we plan to add these at some point in the future.

From C this function can be called in 3 different ways as in these
examples:

  guestfs_add_drive_opts (g, filename,
                          GUESTFS_ADD_DRIVE_OPTS_READONLY, 1,
			  GUESTFS_ADD_DRIVE_OPTS_FORMAT, "raw",
                          -1);

(the argument(s) between 'filename' and '-1' are the optional ones).

  guestfs_add_drive_opts_va (g, filename, args);

where 'args' is a va_list.  This works like the first version.

  struct guestfs_add_drive_opts_argv optargs = {
    .bitmask = GUESTFS_ADD_DRIVE_OPTS_READONLY_BITMASK,
    .readonly = 1,
  }
  guestfs_add_drive_opts_argv (g, filename, &optargs);

This last form lets you construct lists of optional arguments, and
is used by guestfish and the language bindings.

In guestfish optional arguments are used like this:

  add-drive-opts filename readonly:true

In OCaml these are mapped naturally to OCaml optional arguments, eg:

  g#add_drive_opts ~readonly:true filename;

In Perl these are mapped to extra arguments, eg:

  $g->add_drive_opts ($filename, readonly => 1);

In Python these are mapped to optional arguments, eg:

  g.add_drive_opts ("file", readonly = 1, format = "qcow2")

In Ruby these are mapped to a final hash argument, eg:

  g.add_drive_opts("file", {})
  g.add_drive_opts("file", :readonly => 1)
  g.add_drive_opts("file", :readonly => 1, :iface => "virtio")

In PHP these are mapped to extra parameters.  This is not quite
accurate since you cannot omit arbitrary optional parameters, but
there's not much than can be done within the limitations of PHP
as a language.

Unimplemented in: Haskell, C#, Java.

This structure has accreted over time.  Rearrange the types
into a logical order.