Improve the error messages for command I/O errors

[edmorley]

Similar to #355 but for I/O errors from spawning a Command instead of from file operations.

Such Command I/O errors are only likely to happen in the case of a bug, so the error message now says as much. The error also now generates the program name from the command, so avoid it getting out of sync. The command's args are intentionally omitted, since they aren't relevant for errors that occur when spawning a command. (ie: For command not found, it's the program that's not found, not the args.)

GUS-W-12650236.

[schneems]

Looks great! Comments, no request for changes:

• For debugging these failures, I wrote https://github.com/schneems/which_problem but haven't touched it in a long time. (An FYI if you're interested in poking at it or improving it).
• Re the message in the commit: If you moved this into a different module and changed the visibility, you could guarantee that the string came from an &mut Command by forcing programmers to go through your interface:

pub(crate) struct CommandIoError {
    program: String,
    io_error: io::Error,
}

impl CommandIoError {
    pub(crate) fn new(command: &mut Command, io_error: io::Error) -> Self {
        Self {
            program: command.get_program().to_string_lossy().to_string(),
            io_error,
        }
    }

    pub(crate) fn program(&self) -> &str {
        &self.program
    }

    pub(crate) fn io_error(&self) -> &io::Error {
        &self.io_error
    }
}

Not needed, just mentioning an alternative.

[edmorley]

For debugging these failures, I wrote https://github.com/schneems/which_problem but haven't touched it in a long time. (An FYI if you're interested in poking at it or improving it).

Yeah I'd glanced at it a while back - the reason I'm not using it here, is that these Command I/O errors are:
(a) internal errors that will mostly likely only ever be seen by buildpack maintainers if they've happened to introduce a bug (vs user-facing messaging)
(b) only encountered in fairly controlled circumstances (inside a CNB build's container, where there a lot more knowns than eg on a host machine if this project were instead say a CLI tool for end users)

...so we don't need the full feature-set supported by the which_problem crate - which makes it hard to justify the 500+ lines of non-test Rust in which_problem, plus a dozen transitive dependencies:

$ cargo tree
foo v0.1.0 (/Users/emorley/src/foo)
└── which_problem v0.1.0
    ├── is_executable v1.0.4
    ├── itertools v0.10.5
    │   └── either v1.15.0
    ├── ordered-float v3.9.2
    │   └── num-traits v0.2.19
    │       [build-dependencies]
    │       └── autocfg v1.4.0
    ├── rayon v1.10.0
    │   ├── either v1.15.0
    │   └── rayon-core v1.12.1
    │       ├── crossbeam-deque v0.8.6
    │       │   ├── crossbeam-epoch v0.9.18
    │       │   │   └── crossbeam-utils v0.8.21
    │       │   └── crossbeam-utils v0.8.21
    │       └── crossbeam-utils v0.8.21
    └── strsim v0.10.0

...vs the <20 lines of implementation here.

For projects that need the full feature-set of which_problem, this may be a worthwhile trade-off of course :-)