Add thiserror for better display error formatting

[yukibtc]

Description

Resolve #555

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[rajarshimaitra]

Concept ACK..

One extra change for from impls as we are using thiserror so lets use its full power..

[rajarshimaitra]

Review ACK.. Changes looks good to me.. Would let others comment with their take on using thiserror as a dep..

[notmandatory]

I'm in favor of this approach, but since it's adding a new dependency I think we should discuss also at our next bdk dev call, I've added it to the agenda.

[notmandatory]

@afilini in our call today we discussed making thiserror an optional dependency, but on second thought I don't think there's a reason to make it optional since it only adds macros to generate nice looking std::error::Error implementations, so doesn't change the bdk lib API and has no requirement to also use anyhow.

[danielabrozzoni]

I don't think there's a reason to make it optional since it only adds macros to generate nice looking std::error::Error implementations

The reason for making it optional is that some projects want to cut dependencies to a minimum, and wouldn't use bdk if we include too many.

I agree with @afilini that it would be nice to have thiserror but behind a feature enabled by default

[yukibtc]

Add thiserror as optional dependency, in my opinion, make the code more messed up, less maintainable.
If you prefer to have fewer dependencies, it's better to avoid to add thiserror also as optional dependency and continue in the way of PR #814.
The result of PR #813 and #814 for the dev that use BDK library is the same, but for you the work it's doubled when you need to make some changes to error enums (using the approach of thiserror as optional feature).
Keep both approach it's a bad idea, in my opinion.

[notmandatory]

Add thiserror as optional dependency, in my opinion, make the code more messed up, less maintainable. If you prefer to have fewer dependencies, it's better to avoid to add thiserror also as optional dependency and continue in the way of PR #814. The result of PR #813 and #814 for the dev that use BDK library is the same, but for you the work it's doubled when you need to make some changes to error enums (using the approach of thiserror as optional feature). Keep both approach it's a bad idea, in my opinion.

I agree if we want to avoid making thiserror a required dependency it's better to just go with your approach in #814.

Reviewers, please check out #814, I've targeted it for the 0.27 release.