Implement AsRawFd and FromRawFd for ReadDir

[hvenev]

Most unixes provide dirfd(), which can be used to get a file descriptor from struct DIR *.

The two errors are EINVAL (dirfd called on invalid pointer), which can't occur in correct code, and ENOTSUP (not supported by implementation), which doesn't occur on most implementations.

Most unixes also provide fdopendir(), which opens a file descriptor as struct DIR *. It fails if the file descriptor is invalid or if it fails to allocate memory.

[zopsicle]

ReadDir internally stores the path that was passed to read_dir, so that it can be prepended to the file name when calling DirEntry::path. This means a potential FromRawFd impl would not work, as the path is not available.

So we would need to find a workaround for this, such as defining a method that takes the path instead of implementing FromRawFd, or we could document some caveat on DirEntry::path that it won’t work if the ReadDir was created using FromRawFd (e.g. have it panic).

(Note that DirEntry::metadata should work fine without the directory’s path, as it already uses dirfd and fstatat.)

[the8472]

We could try recovering the path by doing a readlink on /proc/self/fd/<fd>, but that's not 100% reliable since procfs may not be available or the path can be too long for readlink. A second fallback would be just putting inthe proc path, as long as it exists. And as last resort we could panic.
But it might be a bit unexpected though if FromRawFd does syscalls or panics.

In addition to FromRawFd we could also provide a constructor method that takes a Path and a file descriptor.

[zopsicle]

With I/O safety being stabilized this issue should also include implementing AsFd, From<OwnedFd>, and From<ReadDir> for OwnedFd.

[the8472]

I don't think we can provide AsFd due to the API requirements of fdopendir(). After #120426 we may be able to provide it on some platforms, but it won't be fully portable so we either have to hide it behind cfgs or make the API fallible.