Restructure ErrorKind into categorised sub-enums

[srxg]

Restructured ErrorKind into FundamentalError, ValidationError, and ThirdPartyError enums.

[Keats]

That doesn't look like it would change much for the user?

[dsykes16]

This would be a breaking change for most dependents of this crate and I also don't see how it changes anything aside from making error handling code on the consumer side even more verbose.

[srxg]

@dsykes16 @Keats

I also don't see how it changes anything aside from making error handling code on the consumer side even more verbose.
That doesn't look like it would change much for the user?

The goal was to make it trivial to answer a very common question: "was this failure a validation error or something else?". That's important for downstream behaviour.

This would be a breaking change for most dependents of this crate

To avoid breakage and extra verbosity, I'm happy to rework this as an additive API, potentially in the below example's direction:

pub enum ErrorCategory { Fundamental, Validation, ThirdParty }

impl ErrorKind {
    pub fn category(&self) -> ErrorCategory {  todo!() }
    pub fn is_validation(&self) -> bool { matches!(self.category(), ErrorCategory::Validation) }
}

impl Error {
    pub fn category(&self) -> ErrorCategory { self.kind().category() }
}

this addresses both concerns: api for a valid need, with minimal surface change.