zmq_sys::ZMQ_RCVMORE returns a c_int

[jannic]

zmq_getsockopt with the option ZMQ_RCVMORE returns an 'int' value. However, get_rcvmore interpreted the result as an i64. While this is technically wrong in case c_int is 32 bit wide, it seems to still work in most cases, as the bit representation of 1i32 and 1i64 is identical on little-endian systems.

However, on big-endian systems, it fails. This can be reproduced on the debian s390x port, where cargo test fails with:

test test_monitor_events ... FAILED

failures:

---- test_monitor_events stdout ----
thread '<unnamed>' panicked at 'assertion failed: server.get_rcvmore().unwrap()', tests/monitor.rs:47:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'test_monitor_events' panicked at 'called `Result::unwrap()` on an `Err` value: Any { .. }', /home/jan/.cargo/registry/src/github.com-eae4ba8cbf2ce1c7/timebomb-0.1.2/src/lib.rs:45:18

To fix this, get_rcvmore should interpret the return value as an i32.

(Technically, c_int would be more correct than i32. But the getter generated by getsockopt_num!(c_int, i32) in src/sockopt.rs already maps c_int to i32. This may be an issue on systems where c_int is a 16 bit value. But I doubt zmq will be used on such a system in practice.)