Implement `epoll`

[sunfishcode]

As reported here, this is needed for cargo-watch.

epoll has turned out to be fairly tricky, because rustix's epoll API does a significant amount of work to present a safe API, which turns out to be complex to re-expose as an unsafe C API. I started some work here toward having rustix also expose an unsafe API for epoll as well, though it's not complete yet.

[carbotaniuman]

Not sure if this should go here or rustix proper, but here are just some API thoughts.

I think honestly the overall API isn't that bad, but I can't figure out how to use Context to actually pass the context data to the API. Perhaps just letting a user pass a u64 in should be good enough. And instead of having to manually deal with a Vec for the return, something like what is used for reading into buffers.

In fact, all of the read syscalls passing in slices should use ReadBuf, as it's actually very subtle UB right now, but that's far in the future UB. Realistically, we could just take in a slice and call it a day until std hammers out these semantics.

[sunfishcode]

The trick with Context is that a very common use case is for the u64 to be used to hold a file descriptor. rustix intends to offer an I/O-safe API to users, so it needs a way to manage the context so that it can convert from the u64 back into a OwnedFd or BorrowedFd before the user sees it. Take a look at how Owning works in tests/io/epoll.rs in the rustix tree, for example.

[sunfishcode]

Rustix's epoll API no longer has a Context, as of bytecodealliance/rustix#487 which is released in rustix 0.37.0. It should be easier to implement epoll in mustang now.