Expand the scope of std::process

[alexcrichton]

Like #939, this issue is intended to collect information about the expansion of the std::process module. As with most of the rest of the I/O reform, the goal of std::process was originally to be quite conservative. Over time we knew we were going to want to expand the module after we got experience using it as well as seeing how this sort of expansion plays out in the bigger picture.

I'll list some pieces below of parts I think that could be expanded, and I'll try to keep the list updated over time:

• The I/O handle types do not expose their internals. This means that on unix even though a pipe is known to be a file descriptor, the file descriptor is not accessible for interoperation with other I/O libraries.
• It is not possible to specify a custom I/O handle as one of the stdio descriptors. For example on unix the stdin could be specified as a specific file descriptor which already exists. This functionality needs to be fleshed out on Windows first. - std::process should provide a facility to specify custom file descriptors to stdin/stdout/stderr #893
• Process spawning should expose dropping capabilities on linux - Process spawning should expose the ability to drop capabilities on linux rust#12137
• File descriptors may be leaked when spawning processes - Danger of leaking file descriptors when spawning processes rust#12148
• Spawning a daemon process is not currently possible (on either windows or unix)
• A post-fork function to execute on unix would be useful for fine-tuning behavior for the child
• Waiting for a child with a timeout on windows is fairly trivial to implement but is not expose currently. (implemented in a separate repo)

As with #939 I don't plan on writing an RFC about this expansion in the near future, but I'd like one place to collect information about how std::process can be expanded.

[l0kod]

std::process should provide a way to deliberately leak file descriptors/handles and get/use them back (i.e. old Command::extra_io, lost with rust-lang/rust#18557), not only stdio.

[alexcrichton]

Certainly, I consider that to fall under the "It is not possible to specify a custom I/O handle as one of the stdio descriptors" umbrella where we're not really leaking them per-se but you should be able to specify that an existing file descriptor should exist as another in the new process.

[l0kod]

A post-fork function (cf. #579 (comment)) seems to need properties similar to FnAsync (i.e. signal handler) to be safe.

[nagisa]

Need to add a way to wait for children with a timeout.

[genodeftest]

I need a way to check whether a child process is still running or not.

[l0kod]

Is there any plan to re-add detached(&mut self) to std::os::unix::process::CommandExt? Is there another way to do it without a manual unsafe fork(2) handling?

cc @aturon