give RBTs an explicit interface
a draft signature and test for zippers

You can check that if you comment out the `balance` call in the
`close` function, the property will fail.

There are two problems with this first try at testing RBT zippers:

- I cannot say that when a (foo option) actually returns a (Some v),
  we can populate (foo) with (v). So I had to lift everything at the
  level of (foo option). I think we may need to add constructors for
  products and sums at either the Ty or Fn level.

- The current implementation is *very* slow on this example. It feels
  like it is exponential in the number of operations of the signature.
add a cutoff to element generation to terminate on large signatures
move back to a memory-efficient representation of RBTs
make color its own type again, rather than boolean
Makefile.
.gitignore
Comments.
fix the balancedness test for RBT: red children must be black
Enable some reasonable warnings.

There were a few cases of unused variables.
More comments.

Also, a new make doc target.
Ignore the doc/ directory (auto-generated documentation).
remove read/write from the RBT zipper interface

They made the last balancedness test (in presence of zippers) fail,
because their specifications are buggy. An ironic evidence of the
usefulness of interface testing?

The read function allows to observe an arbitrary subtree of a RBT,
which may not be balanced as it may start with a red node. The write
function allows to replace it with any other RBT, which also breaks
balancedness as one may insert a tree with a different black height
than its sibling.

This removal is a bit unsatisfying as it makes the zipper interface
basically useless. There are several possibilities of functions one
may want to add:

- on non-leaf nodes, we may want to access the ('a) element; such
  a function would be partial as current 'pointers' may also point to
  Empty nodes. We cannot allow "write" of ('a) in general, as this can
  break the sortedness property, but we might allow "write" if it
  inserts an element that compare equals to the existing one
  (useful for example if one models a mapping from integers to foo as
  a (int * foo) RBT.t, with a comparison function that only depends on
  the int part)

- on leaf nodes, we may want to insert a new ('a) element; of course
  this requires some rebalancing logic corresponding to the 'insert'
  function.

None of these are immediate/easy to implement, and I'm working on
other parts of the framework for now (native support of sums
and products).
remove 'let open' which my old Tuareg doesn't like
Use a single function for creating new ['a ty]s.

This fixes #16.

@gasche: your previous commit didn't compile.
WIP
Big modification
- using sets implemented as lists is way too slow, so let's use a
poor's man polymorphic sets implemented using RBTs. By the way, there
is a problem with the current code, when it comes to the insertion of
one element that is already there.
- there is no real reason to use fix, I think. That is, the graph of
dependency between types is static, so we can always compute it before
hand. Fix would be nice if the dependencies were unknown, or dynamic,
but this is not our case. Right now, my implementation is pretty
disgusting, but this is a good start.
Complete refactoring of the graph based branch. Lost many comments in the process...
Close issue #14
Merge pull request #21 from braibant/graph-based

Graph based implementation