# Rationale for this change

In order to make this rep `no_std` compatible, we need `no_std` compatible errors. `thiserror` is not `no_std` compatible, while `snafu` is. We are currently using `thiserror`.

Note: While dtolnay/thiserror#304 is an open PR, it is not clear how soon this will get merged. Additionally, Substrate uses `snafu`, which would help unify dependencies for Substrate-based integrations.

# What changes are included in this PR?
NOTE: the individual commits may be good to review individually.
- All error enum variants consisting of tuple structs are transformed
into named structs. This is necessary because `snafu` does not support
tuple structs.
- Every `#[derive(Error)]` is substituted with the analogous
`#[derive(Snafu)]`. In particular:
* `#[error(...)]` attributes are substituted with equivalent
`#[snafu(display(...))]` attributes
* `#[error(transparent)]` attributes are substituted with equivalent
`#[snafu(transparent)]` attributes (which also derive the corresponding
`From` implementation)
* For `ConversionError::TimestampConversionError`, the
`#[snafu(context(false), display(...))]` attribute is used for deriving
a `From` implementation, and at the same time maintain the custom error
message
- A `std` feature is introduced for the `proof-of-sql` crate, which in
turns activates the `snafu/std` feature. The `std` feature is required
for the `posql_db` example, because `Clap` relies on the
`std::error::Error` trait.
- `thiserror` still appears in the dependency tree (`cargo tree -i
thiserror`), but only as a transitive dependency (via `blitzar`, and
dev-dependencies)

# Are these changes tested?
Yes. This PR is a refactoring, and all existing tests pass.