Add an ability to read exit code and specific streams

[Deniallugo]

Description

This PR enhances the functionality of the crate by adding the ability to read both the necessary stream and the exit code of a process.

Motivation

First, I want to commend you on creating such a fantastic crate. It has significantly streamlined my work with processes, saving me a lot of time and effort.

The current implementation assumes that the presence of stderr indicates a non-zero exit code, which is not always accurate. In my application, this distinction is crucial because I need to print stdout directly while only reading stderr. Additionally, not having direct access to the exit status forces me to parse stderr for all possible scenarios, making the process error-prone and inefficient.

Check status doesn't fulfill my needs, because I'm either getting the exit status or stderr. And I'd like to have both

Changes

Added functionality to read the exit code of a process altogether with the specified stream.

[matklad]

🤔 I think the idea is that this use-case should be handled by the fn output method, which returns an std::process::Output -- the most low-level and flexible interface.

So, I'd rather not add an extra StreamOutput type, and keep only two levels of abstraction:

• I want to treat non-zero code as an error and want to get the output as a string -- fn read
• I want to manually handle all streams, decoding, and exit code -- fn output

Though, as it stands I think fn output doesn't allow the logic of "inherit stdout, but capture stderr", it always captures both.

---

In terms of actionable things:

• What you could do right now is to use From<&Cmd> for std::process::Command impl to get the std::Command which provides you with all customizability.
• Adding StreamOutput is not something we should be doing, we should enable Output
• Extending the API to make fn output selectively inherit streams sounds good to me, as long as it preserves backbards compatability. After DRAFT: Simplify the API and inner implementation #85 is merged (cc @elichai), I'd love to take a holistic look at how we can simplify the API overall. I think this PR illustrates a good end-goal: "API that gets you std::process::Output while allowing fine-grained customization".

[Deniallugo]

Great, Thank you! I'll try this direction!