Add conversion from tokio::process::Command to std::process::Command

[czy-29]

Is your feature request related to a problem? Please describe.
The reverse conversion currently exists, but the conversion from tokio to std (with ownership) does not currently exist.
The as_std and as_std_mut methods only return references, and because std::process::Command is not Clone, its ownership cannot be moved out through simple dereference. Therefore, a separate conversion method which can move out ownership is needed.

Describe the solution you'd like

impl From<Command> for StdCommand {
    fn from(cmd: Command) -> StdCommand {
        cmd.std
    }
}

Describe alternatives you've considered
Or some named methods such as:

pub fn into_std(self) -> StdCommand {
    self.std
}

[czy-29]

Since this feature is relatively easy to implement, opening this issue is mainly to initiate some discussions and see if there are any reasons that I have not considered that actually make this feature unnecessary. We can also discuss which solution we choose to implement it with. If everything is clear, then I am willing to directly submit an associated PR.

[Darksonn]

Thoughts @ipetkov ?

Since we already have as_std_mut this may be okay ... but the tokio::process::Command type may have additional options that are not reflected in the std::process::Command type. Right now it's only the kill_on_drop boolean, though.

[ipetkov]

I suppose it would be fine. Most of the tokio-specific logic happens on spawn (and not before we forward calls to the std version) and since we already expose as_std_mut we might as well support unwrapping it. Yeah you'd lose the tokio-specific data, but I don't imagine the caller would care too much if they're interested in the std type (or else they'd be working with the tokio version directly)

[czy-29]

I suppose it would be fine. Most of the tokio-specific logic happens on spawn (and not before we forward calls to the std version) and since we already expose as_std_mut we might as well support unwrapping it. Yeah you'd lose the tokio-specific data, but I don't imagine the caller would care too much if they're interested in the std type (or else they'd be working with the tokio version directly)

Which signature do you expect to implement?

1. impl From<Command> for StdCommand
2. pub fn into_std(self) -> StdCommand
3. pub fn unwrap_std(self) -> StdCommand

[ipetkov]

We can start with just into_std since we already have precedent for that style of API