Fix embarrasing bug in `Val_cons` callsite

Embarrassing bug introduced in #71. Apologies about that!

Interestingly, this bug did not cause segfaults in our code, and often caused results which were close to the expected ones:

if the socket becomes readable, we were doing Val_cons(Val_int(0),Val_emptylist) which built the OCaml pair ([], 0) which represents the list [0] (the expected result, no bug is observable).
if the socket becomes writable, we were doing Val_cons(Val_int(2),Val_emptylist) which built the OCaml pair ([], 2) which is not a valid list but since the compiler only checks the whether the tail is an integer to decide whether the list has ended, this value was being interpreted as [0], which means the socket was being reported as having become readable (wrong result, but often hidden if one tries to do a non-blocking write each time the socket becomes readable).
if the socket becomes both readable and writable, we were doing Val_cons(Val_int(2),Val_cons(Val_int(0),Val_emptylist)) which built the OCaml pair ((0,[]), 2). Again, this is not a valid list, but for the same reason mentioned in the previous bullet point, this is interpreted as [[0]]. Since the list elements are expected to be integers, and only List.mem was being applied to it, this ended up being interpreted as [] (=> wrong result, supppressed events coming from select)...

ygrek / ocurl