fix: read Command output ending with a carriage return, closes #3508

[lucasfernog]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

The process::Command API will now read lines until a \n or a \r is found.

[chippers]

This looks ok to me in general. Ideally we wrap the PipeReader stuff inside a function so we can reuse the logic exactly for stdout/stderr.

The only required change that is requested is the unwrap() one, or an explanation of it added to the code in a comment.

As far as logic goes, I don't see anything wrong. There's more room for optimization with memchr (I think), but I really don't see the point if this isn't proven to be a bottleneck. It can always be done later since this approach doesn't really lock anything into public api