Make error diagnostics for byte count flags (`--skip`, `--length`, `--display-offset`) awesome by ErichDonGubler · Pull Request #98

Make error diagnostics for byte count flags (`--skip`, `--length`, `--display-offset`) awesome by ErichDonGubler · Pull Request #98 · sharkdp/hexyl

…r reporting flexibility

This significantly changes the structure of potential output of
top-level errors.  Before, errors that have a `source` were printed on a
single line, with the `source` omitted. Now, an error with a `source`
will be printed like:

```
Error: <`Display` impl of error>

Caused by:
    <`Display` impl of `source` error>
```

If there are multiple `source` errors in a chain, then it will be of the
form:

```
Error: <`Display` impl of error>

Caused by:
    0: <`Display` impl of first `source` error>
    1: <`Display` impl of `source` of `source` error>
    # etc.
```

Now, in practice this never happened before, since the only error
type that ever could return from `<binary>::run` was `std::io::Error`,
which has no `source`. However, `source`s can start being added if, say,
future work involved using `anyhow::Context::context` or custom errors
that implement `std::Error::source` are added to the codebase. I believe
this is a good choice going forward, but I definitely want to foster
discussion and acceptance for it in the open first!

…actually good

This adds an error type called `ByteCountParseError` with a vanilla
`std::error::Error` implementation. The code could be significantly
compressed with a dependency like `thiserror`.

I opted to implement a separate error type for `parse_byte_count` rather
than using `anyhow`'s small ecosystem of error types there (though they
are used in `<binary>::run`) because it allows pairing diagnostic
results with tests, incl. those already written. This can be helpful in
preventing regressions in error diagnostics.