Update use of libc::timespec to prepare for future libc version

[wesleywiser]

In a future release of the libc crate, libc::timespec will contains private padding fields on 32-bit *-linux-musl targets and so the struct will no longer be able to be created using the literal initializer syntax.

The only uses in this crate of libc::timespec in this way were zero initializing the struct. Thus, these can be replaced by a call to std::mem::zeroed() which is compatible with both current versions of the libc crate as well as the future version which will contain those private padding fields.

I tested this locally both with a modified libc/i686-unknown-linux-musl target and with the current libc/i686-unknown-linux-musl target. The code builds and all tests pass. The GH workflow required disabling a deny(warnings) for new warnings that are emitted since the last time the branch was built but it succeeded other than the test-old tasks which failed because of dependency resolution errors with the cfg-if crate.

Related to rust-lang/libc#2088

[jhpratt]

This will be released as soon as I can fix CI. It's changed a fair amount since the last 0.1 release.

[jhpratt]

Well, CI passes when using the latest stable, but fails with a linker error on MacOS on 1.21.0. I am able to successfully cross-compile it from Linux to MacOS on 1.21.0, so I'm releasing as-is. We'll find out soon enough if there are any issues 😄

[wesleywiser]

Just FYI that seems to be a common issue with older Rust versions on newer macOS versions: Amanieu/parking_lot#363 (comment)

Thanks so much for your help with this!

[jhpratt]

Well, so be it. I figured if I could cross-compile it, then there was no true issue. Thanks for doing the legwork of the various patches.