Add more `ErrorKind`s

• A somewhat related tracking issue #86442

Misc UNIX

Originally posted by zackw in https://github.com/rust-lang/rust/issues/79965#issuecomment-810468334

I am surprised to see EMFILE, ENFILE, ENOMEM, ENOEXEC, EIO, ENOTTY, ENXIO, ENODEV, EOPNOTSUPP, ESRCH, ECHILD, and EINPROGRESS dismissed as unlikely to occur, or only relevant to people doing highly Unix-specific tasks. They can all happen at least as easily as some of the other situations for which codes are being added. I'd recommend all of these be added, with the following friendly names and descriptions. Some of them should be lumped together, however.

• EIO: PhysicalIOError, "Data could not be input or output due to a hardware failure, such as a bad disk sector."
• ESRCH and ECHILD: ProcessNotFound (or lump with the existing NotFound). "A process was not found" seems too vague and short, but the existing description for NotFound is also vague and short, so 🤷‍♂️
• EINPROGRESS: InProgress. "An operation has begun, and will complete later. It is not yet known whether it will succeed."
• EMFILE and ENFILE: TooManyOpenFiles. "The process cannot open any more files without closing some first, or the system as a whole cannot handle any more simultaneously open files."
• ENOMEM: NotEnoughMemory. "The system does not have enough free memory to satisfy an allocation request. This can happen either because all of RAM is already allocated, or because the request was for more memory than the computer has."
• ENOEXEC: InvalidExecutable. "A machine-language program is either corrupt or cannot be executed on this CPU (e.g. it is machine code for some other type of CPU)."
• ENOTTY, ENXIO, ENODEV, EOPNOTSUPP: NotOperable, "This operation cannot be applied to this type of file or device. For example, changing terminal settings on something other than a terminal device."

EMFILE specifically

Was requested at least a couple of times

• https://github.com/rust-lang/rust/issues/86442#issuecomment-1584846511
• https://github.com/rust-lang/rust/issues/86442#issuecomment-2163167135

(I was not even looking for those, just noticed the reoccurring request while gathering info for the few previous issues I've opened.)

Start with the existing ErrorKind definitions and the Unix errno handling, then read tracking issue #86442 and the linked historical discussion for prior context. Done means the requested errno cases have agreed names, groupings, and descriptions and are represented consistently in the relevant Rust error APIs.