mirari updates

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Vincent Bernardoff's been fixing up Mirari over at Citrix. I've merged all
the latest changes into http://github.com/mirage/mirari -- let's use that
instead of Thomas' repository for pull requests from now on.

I think we're ready to start moving all the docs on the website over to
Mirari now. Do you have your Xen kernels all working now Vincent?

There's one main thing missing from Mirari now: the run target to execute
the kernel.  Some hacks to beware of:

- In the UNIX backend, in mirage-platform/unix/runtime/tap_stubs_*.c,
  we currently hardcode an `ifconfig 10.0.0.1` to give the tap device
  a static IP address.  This has made it easy so far to get networking
  up and running, but the tap device setup really ought to be done by
  Mirari-run instead of the Mirage-platform libraries (which should just
  open a tun passed to them).

- In the Xen backend, we need to generate a config file that also includes
  the bridge information for the VIF.  Right now the mirari.conf file
  doesn't include the bridge (only the IP address/DHCP), so it will need
  to be added as part of run support.

- libvirt seems to be the best option to actually execute the kernel. Has
  anyone tried this yet -- Dave?

On the configuration/build side, I've been thinking that Mirari should
also run the compiler directly using the 4.01.0+mirage-xen switch.  This
will let the developer have their normal OPAM switch be one that can
generate UNIX binaries (and also let Mirari depend on Core/Async/etc which
can be part of the host toolchain and not the Xen one).  

Thomas: what's the best way to get OPAM support for this... I guess we
need a way to spawn a subshell under a particular switch:
e.g.: $ opam config env -s 4.01.0+mirage-xen
That would then call obuild which would work correctly. Thoughts?

-anil