[liblo] option API

Hi,

I would like some feedback on this idea, pushed as a branch called 'options'

Currently we now have a 'flags' API for lo_address and lo_server.
Since this seems a bit inflexible as a general "options" mechanism,
for future-proofing this design decision, I propose being able to at
least provide an argument for each option, rather than only being able
to specify boolean bitflags.

https://github.com/radarsat1/liblo/commit/06e65feb559fe729fba077a5eb998d84d20c33cd

In the proposal, each option is set individually with an argument, eg,

lo_address_set_option(a, LO_ADDRESS_SLIP, (void *)1);

As you can see, a downside of reserving the argument as a void*
pointer is that it requires an ugly cast for integer/boolean
arguments.

I haven't figured out a better way to do this.  The only other
suggestion I had was to use a union called lo_option, allowing,

typedef union {
    char *s;
    void *p;
    int i;
} lo_option;

lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option)1);

But this still requires an explicit cast and depends on a GNU C
extension.  Although, I believe the following is valid C99:

lo_address_set_option(a, LO_ADDRESS_SLIP, (lo_option){1});

Either way it's a bit uglier than I was hoping for...
I guess another possibility would be to have two arguments, one for
integers and one for pointers:

lo_address_set_option(a, LO_ADDRESS_SLIP, 1, 0);

where the last argument is reserved for future use as a string or
struct pointer.

Any opinions?  Alternatively maybe this is putting the cart before the
horse, but I'd rather not be stuck with yet more inflexible functions.
 In retrospect we could have used such an API for setting the
multicast TTL and interface, for example, instead of having special
lo_server constructors and special functions for those cases.

(Another point of view is that having lots of dedicated functions is a
good thing since it allows capabilities to be easily detected by
autotools...)

Steve