Rust error stratergy in the hg codebase

[Raphaël Gomès]

Hi all,

I've been having an ergonomic issue with error handling lately. Error 
handling strategy used to be kind of a rough edge in Rust because of the 
different constraints of both the compiler and the standard library. 
Lately it seems that most projects are happy with using a mix of 
`thiserror`/`anyhow`/`eyere`/`snafu`, however when investigating using 
(a potential combination) of them, they don't appear to allow for all 
the constraints that we have.

Rust errors in the hg codebase:

- need to be matchable at the library layers (basically that everything 
inside `hg-core` exposes enums)
- need to carry enough information for end-users to make sense of the 
issue and/or devs to be able to help end-users with it
- need to match the Python implementation's user-facing behavior 
basically exactly (we can have some leeway for OS errors, I guess, but 
the point is to leave the formatting to us and not a library)
- shouldn't do any formatting inside `hg-core`, that should be left to 
consumers of `hg-core` (though having a default formatting isn't a bad 
idea for debugging)
- shouldn't assume that data is somehow UTF8 (ties in to the last 
point), as we have non-UTF8 data we need to format using `format_bytes` 
or equivalent (no popular crate seems to care since it's a pretty niche 
need)
- need to compose somehow, since not all code can be perfectly 
hierarchical: the `dirstate` module needs to call functions that may 
return a `RevsetError` and the `revset` module needs to call functions 
that may return a `DirstateError`, creating cycles in error enums (this 
is the big one for me that started this refactor and questioning).

So I'm calling to the Rust experts, or at least people that have some 
experience with working in larger Rust codebases about what the optimal 
strategy would be.

Thanks,
Raphaël