Provide an API for `std::process::Command` to set `CreateProcess` flags on Windows

[luser]

Updated report

Now a tracking issue for CommandExt::creation_flags on Windows.

Open questions:

• Should we provide a method of adding flags as opposed to setting them entirely? Would be a bit more composition-friendly.

Also, don't forget to add to the prelude when stabilizing!

Original report

There's a currently-unused codepath in the Windows implementation of std::process::Command::spawn that can set DETATCHED_PROCESS:

rust/src/libstd/sys/windows/process.rs

Line 162 in b1363a7

flags |= c::DETACHED_PROCESS | c::CREATE_NEW_PROCESS_GROUP;

It looks like historically there was a method to set this but it got removed. Unfortunately there's currently no way to set this, and no other way to set the CreateProcess flags, so for a project I'm working on I basically had to reimplement spawn for Windows:
https://github.com/luser/sccache2/blob/89f4b44d01084846893a64137d965ee844fe2d72/src/commands.rs#L103

I think we need some way to set this, even if it's Windows-specific. There are a bunch of other flags that can be specified, so maybe a way to set arbitrary flags would be useful?
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684863(v=vs.85).aspx

I think this would fit nicely onto a Windows equivalent of the std::os::unix::process::CommandExt trait, maybe something like:

trait CommandExt {
  fn process_flags(&mut self, flags: u32) -> &mut Command
}

[sfackler]

Seems reasonable to me!

[alexcrichton]

👍

[retep998]

I'm always in favor of adding more Windows specific extension traits to expose useful functionality that other platforms don't seem to have.

[luser]

I have a patch, it just took me a while to write a test for it. I'm trying to sort out the stability annotations for the new APIs--can I just use this issue as the tracking issue for the new feature?

[alexcrichton]

can I just use this issue as the tracking issue for the new feature

Sure!

[luser]

To the open question: I had first written the API as originally proposed: with a creation_flags method to set the flags directly. Then I thought that might make it difficult if callers wanted to set different flags in different places, so I split it into set_creation_flags and add_creation_flags methods, but Alex asked me to change it back. I'm not sure it's that important, I don't think there are that many process creation flags that it would be useful to set from a library context, and callers can always aggregate flags into a u32 and just call creation_flags with that value.