Reconsider use of error handling crates #14
Description
Is your feature request related to a problem? Please describe.
Currently, our error types do not use external crates, which forces us to implement traits such as Display manually and adds a lot of boilerplate code.
This was unavoidable, as the Error trait that most error handling libraries are based on was part of std up until recently, which prevented using them in no_std environments.
Describe the solution you'd like
As the Error trait will be moved to core with the next stable Rust release (rust-lang/rust#103765) and will therefore be available in no_std environments, we should reconsider the usage of error handling crates in order to remove some boilerplate.
As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports no_std (dtolnay/thiserror#304).
Describe alternatives you've considered
We could also keep the existing code and not switch to thiserror.
This would allow us to keep supporting older Rust versions (using thiserror with no_std would probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.