[PATCH 00 of 32 RFC] libxl: drop device_model_info, better defaults support, stubdoms by default

[Ian Campbell <ian.campbell@citrix.com>]

My original intention with this series was to introduce the ability
for users of libxl to explicitly say "pick the default". Mainly by
introducing the libxl_defbool type but also by arranging more
generally that leaving a value set to zero means "default".

However it turned into something of a yakk shaving excercise and so
contains the following:

* Removes support for comments in the IDL language itself. Generating
  comments in the generated files is not all that useful so lets just
  use source level comments in the .idl instead.

* Switches to using keyword arguments for Fields in Aggregate types
  instead of a variadic tuple.

* Removes libxl_device_model_info from the library API. The use of
  a device model to supply specific features is really an
  implementation detail within the library and not something users of
  the library should need to be concerned with.

  Many of the fields of the struct we really guest configuration
  details, e.g. VNC setup and therefore belong in
  libxl_domain_build_info.

  This struct also contained a number of things which were duplicated
  from the build_info and which could never sensibly differ in this
  context (e.g. guest total RAM, ACPI on off etc).

  I have tried to make a determination whether something belongs in
  the global part of libxl_domain_build_info or whether it is HVM
  specific.

  This forms a big part of the series.

* Introduce libxl_defbool and switch to using it.

* Some other changes to arrange that the 0 value means "default". At
  least one instance of this (the timer_mode enum) introduces a wierd
  disconnect between the underlying values and the libxl exposed
  values. I'm not sure that I like this.

* Use device model stubdoms by default when possible.

One question which arised from this change is how we deal with
per-arch options in the future. Do we need to define
libxl_domain_build_info_x86? We could also tag fields with a list of
architectures.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).