Refactor error system

[plafer]

Currently, most of our defined errors are unused (they were previously created for hermes needs). This creates confusion in how to use the errors properly.

We should also revisit whether we need flex_error, or if instead we want to move to a more canonical & simple error crate such as anyhow.

[mzabaluev]

if instead we want to move to a more canonical & simple error crate such as anyhow.

Anyhow is too freeform for a good library API. thiserror would be great, but it's unconditionally tied to std::error::Error so it's a no go for no_std.

flex_error has the appropriate feature set, the problems I see with it are mainly in readability. The custom macro is less transparent than the minimalistic approach taken by thiserror, is somewhat boilerplatey, and requires user discipline to avoid excessive allocations. It also creates magic constructor function names that cannot be grepped from the source.

[DaviRain-Su]

I've seen std::error::Error moved to the core::error::Error eyre should soon support no_std. hack-ink/array-bytes#18
eyre-rs/eyre#83

[plafer]

After discussing with @romac, a good direction also is to go by this comment's advice. In short, use displaydoc + implement std::error::Error if std is enabled.

The main reason is that we don't need any fancy error functionality in the handlers (e.g. no backtrace functionality needed) that were useful for hermes. Therefore, our "Error strategy" should be equally simple.

[DaviRain-Su]

I think once the core::error::Error stabilizes in a rust stable version, some error processing libraries will be supported soon.