Alternative (and simpler) workflow for binding constants

[yallop]

This pull request adds a second way of binding compile-time constants such as enumeration constants, macro values, struct offsets, union sizes, etc..

Bindings written using the old interface can be reused without change. For example, to create a type corresponding to the following C enum declaration

enum color {
  red,
  blue,
  green
};

you might write:

module Types(T: Cstubs.TYPES) =
struct

  let colors_t = enum "color"
    [`Red, constant "red" int64;
     `Blue, constant "blue" int64;
     `Green, constant "green" int64]
end

Here's how to use the Types functor with the existing existing interface (see also #62):

• Pass the Types functor to
  Cstubs.Types.write_c
  to generate a C program
• Run the C program to generate an ML module of type Cstubs.TYPES.
• Apply Types to the generated module to make the compile-time constants available to your program.

Here's how to use the Types functor with the new interface in this pull request:

• Pass the Types functor to
  Cstubs_structs.Easy.write_c
  and
  Cstubs_structs.Easy.write_ml
  to generate C stubs and an ML module of type Cstubs.TYPES.
• Apply Types to the generated module to make the compile-time constants available to your program.

There's a tradeoff: the new interface is easier to integrate into a build, since the dependencies are less linear. The existing interface generates slightly faster code, since it inlines the values of the C constants into the ML program.

(This isn't quite ready for merge: it doesn't yet support binding the same constant multiple times under different types.)

Closes #266.