really use the production numbers properties to control fixpoint computation
remove the 'constructors' field

Instead of storing constructors in a per-type mutable list (bad!), we
reiterate on the signature, filtering out the constructors that may
produce an element of the right type. This will make adding sums and
products easier.

Note that I had to change the way signature extension is handled in
examples/rbt.ml, to preserve the existing behavior (which may or may
not be the right one). Before, constructors were registered by the
`_val` function, now they depend on the signature being passed. So
when you write something like:

  let rbt_sig = Sig.([
    val_ "empty" (returning rbt_t) RBT.empty;
    val_ "insert" (int_t @-> rbt_t @-> returning rbt_t) RBT.insert;
  ])

  let () = Sig.populate  rbt_sig

  let zip_sig =
    Sig.(rbt_sig @ [
           val_ "Some" (rbt_t @-> returning rbtopt_t)
             (fun z -> Some z);
           ...
         ])

  let () = Sig.populate zip_sig

The previous implementation would populate the rbt_t types during the
(populate rbt_sig) call, and not extend it with new elements in the
zip_sig case (which doesn't add any rbt_t constructor). The new one
will call the constructors of rbt_sig again in the (populate zip_sig)
case, producing a lot more elements.

The new behavior may actually be the correct one, but this requires
more thinking. For now I commented out the (rbt_sig @) part to
preserve the number of generated elements.
add support for sums and products

For now, the arti.ml implementation support sum and product types, but
the arti.mli interface still exports restrictive types for the
combinators (@->) and (returning), assuming they're only passed atomic
types.