new Cohttp interface progress

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

I've been going through the web stack doing releases, and have tagged Re and 
Uri versions.  Cohttp is a little trickier as the code was a little messy 
before, so I've been rewriting it to make it significantly simpler and easier 
to embed in libraries.

https://github.com/avsm/ocaml-cohttp/tree/v2-interface

Instead of depending entirely on Lwt, I'd like to have a version of Cohttp that 
can work with alternative threading libraries like Async. So I've abstracted 
out the io iteration within the protocol library as a new IO module which can 
eventually hide the Lwt type:
https://github.com/avsm/ocaml-cohttp/blob/v2-interface/lib/IO.ml

The Cohttp.IO.M monad looks like an Lwt monad, but since the interface is so 
much smaller, it should be easy to plug in an Async version too.   I've also 
removed all exceptions from the parsing interface and propagate options 
instead.  Exception handling is the main difference between cooperative 
threading libraries, so putting it directly into the control flow makes life a 
lot easier.

HTTP Request parsing works now, but I'm still pondering how to handle HTTP 
bodies with the IO.M interface.  We can't expose an Lwt_stream directly, so 
I'll investigate how Async does iteratee IO and make sure IO.M is compatible. 

Anyway, the reason this is relevant to the list is because Dave wanted to use 
Cohttp, but also because the IO.M technique should be useful for other protocol 
implementations that need multiple threading backends (Xenstore and DNS 
perhaps).  It would be good to figure this out before we embed Lwt really 
deeply.  I'll do some more work on this tomorrow, but ideas welcome...

-anil