Shore up the `grand' protocol.

This is a bit of a mess, really.  There are two main problems.

  * Firstly, the business of comparing function pointers simply doesn't
    work on Windows, because the dynamic linker is too hopeless.  If the
    class implementation is in a different module from Catacomb itself,
    then the vtable may have a pointer to an import-library stub, which
    won't compare equal to the library's idea of the default method
    function.

    It's basically a mistake to have tried to use the same functions as
    both user interface and default implementation.  Split the two
    apart.  Leave the hacky function-pointer comparisons in the user-
    interface functions for compatibility with existing out-of-tree
    generators, which will carry on working about as well as they ever
    did.

    Note, however, that the defaulting strategy is now less `clever',
    and implementations which don't provide native versions of all the
    methods may end up suffering more than they used to.

  * The `grand_range' function was simply broken if the `raw' method's
    output is too small.  Synthesizing a full uniform-value-in-range
    from a narrow primitive generator in single precision arithmetic is
    rather difficult, so rather than do that I've decided to insist that
    all `raw' methods have a range of at least a byte's worth, so we can
    synthesize a word generator out of bytes if necessary, and then use
    that to satisfy the original larger range request.

This is all a bit unsatisfactory, really.  I must remember to revisit it
when all of these gets made out of a proper object system.