Use error types instead of String throughout the crate

[rrbutani]

This PR adds error types (enums with variants for different error cases that have Debug + Display + Error implemented) and uses them throughout the crate in place of String as the error type on Result.

This is a mostly mechanical change; other than fixing some typos, I used the existing error messages in the crate (i.e. the Err(format!(...)) messages).

However, though this is unlikely to affect most users (assuming the typical user of this crate is just using .unwrap()), it still is a breaking change.

Apologies for the massive commit — I couldn't find an obvious way to split it up without introducing commits where the build fails. Hopefully reviewing the PR file by file isn't too onerous; all the changes should be local to the file they are in.

Motivation

I have a bit of a pathological use case wherein binary size is of extreme concern, to the point where the error strings in this crate (and the associated std::fmt machinery needed to generate them) have a noticeable impact on the final binary size¹.

Moving the logic that actually generates Strings for these errors into Display impls and out of the functions in this crate's API allows the optimizer to remove these strings in cases where they are not ultimately used (i.e. where the user calls .unwrap_unchecked() or similarly discards the errors from this crate).

This change also has the benefit of removing String (and dependence on an allocator) from parts of this crate's API which should be helpful for any potential no_std support efforts.

Open Questions

• This PR adds thiserror as a dependency. Hopefully this is okay; thiserror is a proc macro and does depend on syn but it has no runtime dependencies.
• Should some of these error type enums be marked #[non_exhaustive] as a way to sidestep needing a breaking change for future additions to this crate?
• Rather than adding all of these error types to the top level errors module, I added each type to the module where it is used. I think this makes the PR easier to review (the changes to each file are self-contained) and just generally lets us avoid having to jump between files in errors/ and elsewhere in the crate quite as much but if this is undesirable I can update this PR to have all the error types in errors.
• I used some discretion when deciding whether to use the same error type for multiple functions in a module or whether to split the cases out into multiple error types. In general I avoided making new types for functions that are not public and I merged error types whenever it seemed appropriate. I'm happy to update this as you feel is best.

Footnotes

1. Despite using -C panic=abort, turning up the inlining threshold, and making liberal use of unwrap_unchecked, the optimizer is unable to strip these strings out. I think this is because the optimizer is unable to prove that failures in the allocations involved in formatting these error strings ultimately take the same code path as propagating the failure — i.e. the program aborts — but I am not sure; fwiw using -Z oom=panic also does not "fix" this. ↩

[KillingSpark]

This is awesome! It is something I wanted to do for a long time so the breaking change was going to happen sooner or later anyways.

I haven't reviewed all of it yet. But to answer the open questions:

• The extra dependency is fine. thiserror is a widely used crate that adds a massive benefit.
• I think marking the error enums as #[non_exhaustive] is a good idea
• Having the errors in the file where they occur is fine. I think that's how I would have done it nowadays.
• I need to take a closer look at this, but from what I have looked at so far the error grouping seems fine

[KillingSpark]

Thanks a lot for your effort! Don't worry about the clippy error, it's not related to this PR.