cohttp tidyups for 0.9.8

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

I spent yesterday completely tidying up cohttp. It's now much simpler and 
module'd up to the eyeballs, with very little redundancy (see below for 
Lwt_unix, Mirage and Async interfaces).

https://github.com/avsm/ocaml-cohttp/blob/master/lwt/cohttp_lwt_unix.mli
https://github.com/avsm/ocaml-cohttp/blob/master/lwt/cohttp_mirage.mli
https://github.com/avsm/ocaml-cohttp/blob/master/async/cohttp_async.mli

The nice thing per backend is that you can easily see what is extended in an 
OS-specific way. For example, in the UNIX backend, the file functions are all 
separate:
https://github.com/avsm/ocaml-cohttp/blob/master/lwt/cohttp_lwt_unix.ml

The "trick" I learnt from Jeremy and Leo is to avoid functor hell by defining 
more module types to stop the functors propagating. This is what all the 
'module type S' signatures are, and then a functor just satisfies that 
signature.  Kind of obvious now that I see it, but we don't use this pattern 
enough in our protocol libraries!  I've queued up a blog post to write about 
this more before the cohttp-1.0 release.

Before I cut the next release in a few days, I'm going to:

- add a simple ocurl client to satisfy the Client functor with Async
- sync this version with the RWO Async examples (should be very minor changes)
- add a very high-level Http_client functor for Async and Lwt that can be used 
by client libraries (e.g. the Github/Facebook/Google bindings) that just want 
to fetch webpages simply.

Dave, do you want to add your POSIX direct-fd version in a unix subdirectory at 
all?  It should be quite straightforward now if you follow the Async template.

Yaron, I did a (very) quick performance test with httperf of the Async and 
Lwt_unix servers in the lib_test directory, and noticed a significant (3-4x) 
response rate performance drop in the Async server.  Need to queue up some 
profiling here at some point.

One major downside to this approach is that ocamldoc simply falls over.  
Luckily, Leo has an upcoming and much improved ocamldoc that can resolve 
complex module includes and have decent HTML output.  More on that later...

-anil