Replace fn backtrace() with Provider API in Error derive

[ilslv]

Fixes #195 similar to dtolnay/thiserror#182

[tyranron]

@JelteF would you be so kind to move requirement from Test Rust 1.36.0 CI jobs to Test Rust 1.56.0 in master branch protection settings?

[tyranron]

@ilslv hmm...regarding the CI failure. I thought it was because of my changes, but I can reproduce the same test failures localy on your last commit in 2022-09-08 nightly Rust. Could you look into it?

[JelteF]

Food for thought: One of the reasons for this provider API (afaict) is so more types can be provided that just Backtrace, without needing to add more methods to the Error trait.

So probably we want to allow this too, e.g. to embed some additionaly context such as trace IDs in there for distributed tracing. This would probabyl be better as a separate PR. I think it makes sense to keep dedicated and easy to use support for the Backtrace type.

Another idea is to also provide the source through the provider API, like is done in the rust docs

impl std::error::Error for Error {
    fn provide<'a>(&'a self, demand: &mut Demand<'a>) {
        demand
            .provide_ref::<MyBacktrace>(&self.backtrace)
            .provide_ref::<dyn std::error::Error + 'static>(&self.source);
    }
}

Source: https://doc.rust-lang.org/nightly/std/error/trait.Error.html

Again this would be better in a separate PR.

[ilslv]

@JelteF I've already raised question of what should be provided and this implementation mirrors thiserror. As Provider API is quite new and source() default impl still returns None, I think that we shouldn't rush with providing dyn Error and wait how Provider API will be used throughout the ecosystem.

[JelteF]

Looks good overall. but docs need to be updated. Thanks for all the work on this.

[tyranron]

@JelteF ping