Maybe don't use the libc crate

[mahkoh]

Some unstructured thoughts on the state of the libc crate:

1. Kernel types/constants are often duplicated between musl and glibc
2. Types/constants are sometimes present in one but not the other
3. Types/constants are sometimes present for some architectures but not others
4. Posix functions sometimes have an incorrect signature on some platforms
5. Some types have private fields to prevent them from being constructed manually. This policy is applied arbitrarily.
6. Most types do not implement Pod though they should. I see no way to do this right now.
7. Some posix functions are safe on some platforms but not others.
8. 32 bit musl is unsound.
9. The maintainers are not overly responsive.

I tried to address 1, 2, and 3 for syscall constants in rust-lang/libc#1759 but failed.

I tried to address 4 in rust-lang/libc#2021 but this was also shut down.

4 and 5 ignore the different semantics of C and Rust when it comes to implicit casts and object creation. In C, glibc can afford to declare __priority_which_t as an enum due to implicit casts but this does not apply to Rust. In C, structs can be constructed with designated initializers which zeros padding fields but this does not apply to Rust. Instead you have to use unsafe functions and there is no guarantee that our code compiles on any platform except for those that we have CI for. Fixing 6 would improve 5.

I opened an issue for one instance of 7 in rust-lang/libc#2001. This also breaks the build on platforms that we do not have CI for.

8 is because of rust-lang/libc#1848

There are fundamental issues with musl because rustc bundles musl: rust-lang/rust#72274