Refactor error handling

[robo9k]

I'm not quite happy with the current error handling.
There's one MagicError enum for aynthing that can go wrong in the crate and one opaque FfiError for anything that can go wrong when calling libmagic.

I think each function should return a specific error enum that only has the cases that can go wrong in that particular function.
For API stability, maybe the cases should currently not expose more than std:error::Error.
LibmagicError::ApiViolation should rather be an assertion. There's not much the user can do in that case and it might even be unsafe to keep using libmagic in that case.

Some references:

• https://rust-lang.github.io/api-guidelines/interoperability.html#c-good-err (see Investigate Rust API Guidelines #92)
• https://sabrinajewson.org/blog/errors
• https://blog.burntsushi.net/rust-error-handling/

For user convenvience, maybe the one magic "whatever" type should be available to convert into.

thiserror is pretty conventient for development, but adds to dependencies and compile time. Maybe it could be replaced with cargo expand code once the dust has settled.

[robo9k]

As for the CookieDatabaseError from #113 (comment)
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=684549813177ff0388119b8ed55d51c3

[robo9k]

Implemented in #113 and #122

There's no catch-all error for the whole crate.
thiserror is still a dependency.