Re-export header-only functions from liburing

[withoutboats]

Closes #4. This will allow us in iou to delegate all of the prep APIs to liburing instead of being responsible for setting SQEs up correctly.

@twissel would you be open to doing a quick review of this code to check that I didn't get any argument or return types wrong?

[twissel]

Two quick questions: 1) Shouldn't addr https://github.com/withoutboats/uring-sys/blob/73cd794de0ccf9891098b7b3456d480ea5677ebc/src/lib.rs#L251 be declared as mut libc::c_void? const libc::c_void is good for everything except
IORING_OP_READ_FIXED, and indeed it is declared as *mut libc::c_void here https://github.com/withoutboats/uring-sys/blob/73cd794de0ccf9891098b7b3456d480ea5677ebc/src/lib.rs#L269
2) Passing libc::offt as offset in prep{read, write} functions, for example here https://github.com/withoutboats/uring-sys/blob/73cd794de0ccf9891098b7b3456d480ea5677ebc/src/lib.rs#L290 seems strange for me, because at least on my machine this is i64 and we have u64 here https://github.com/withoutboats/uring-sys/blob/73cd794de0ccf9891098b7b3456d480ea5677ebc/src/lib.rs#L64

[withoutboats]

Agreed these are odd, but they're the types liburing exposes. I just checked: io_uring_prep_rw takes the addr as const void *addr and the offsets are passed as off_t.

[withoutboats]

And yea, everything but read_fixed also takes a const pointer, I assume because only read_fixed writes directly into that buffer.

[twissel]

Btw: do you plan to use prep helpers in iou?

[withoutboats]

Yes, to let liburing handle the subtleties of preparing IO events properly.