Document usefulness of this crate more deeply

[Kixunil]

I fail to see a strong reason to use Display and Error derives in this crate. There's displaydoc for Display and thiserror for Error. The examples aren't very convincing either:

Example 1 of Display suggests using a different trait for implementing, which is a bad idea especially in case of Debug - it practically breaks the contract of the Display trait. (Implementing Debug using Display would make more sense logically.)

Example 2 suggests allocation which is again inefficient and it doesn't make sense to write a function returning owned String to implement Display when one could implement Display instead and use .to_string() to get the string.

The remaining Display examples are pretty much what displaydoc supports.

thiserror supports all the features of Error derive in this crate plus also backtraces (I personally don't use backtraces but it's nice to have it available.)

Further looking at some other things:

• I don't see s!() as very useful. If your program needs to allocate strings so often that you want to save 7 characters from the name .to_owned() it is likely that you may want to redesign the program to allocate less in the first place. Methods are generally considered easier to work with than macros/"normal function" by many people, including me. (Prime examples: try!() was turned into ? operator and await was implemented as postfix operator as well.) Finally .to_owned is more readable to the newbies to a project as they don't have to look up what s!() means.
• map! and co are useful, though there's already hmap! for instance. (It looks dead but is there really anything relevant to change? It's simple and works as advertised.)
• Linked list are a terrible data structures and useless in almost all programs. ;) (It's nice having the macro with others but noise in the absence of others.)
• InetAddr with Tor support is great, the question is why it's not in torut itself? It would make more sense to me. Also I'm not sure if its a good idea to name it InetAddr could be confusing since such name exists in std (not hugely against it)
• Would it make sense to add Service to Futures?
• What's the use for Wrapper trait? In my experience newtypes are used in two ways: to protect an invariant and to distinguish meanings of underlying values. In the former case Wrapper trait must not be used as it does no checking (TryFrom<Inner>, Into<Inner> are idiomatic), in the latter case, I found that writing MyNewtype::new(42) is much more readable than 42.into() I avoid implementing From<Inner> for Newtype because of this. For conversion from Newtype to Inner simple into_inner method or From<Newtype> for Inner are more standard in the ecosystem.
• Why AsAny doesn't have blanket impl? I also find it quite surprising that you need to use Any. It's very rarely used. :)
• If Holder is being published it might be worth checking if it can be used with references well and think if there's a better name for it. I'm not even sure if it's useful to publish it because orphan rules might wreck its usefulness - a macro might be better.

[dr-orlovsky]

Thank you for such a detailed review.

The main reason is to have these derives in bitcoin projects where I do not want to rely on any external additional crates from outside of bitcoin community for this trivial functionality.

I will comment on the specifics tomorrow after thorough reading each of the points.

[Kixunil]

thiserror is from David Tolnay, the author of serde, so that shouldn't be a huge issue. :)
displaydoc should be sufficiently easy to review, I think.
At worst, it should be possible to pin the dependencies. Seems cleaner than writing from scratch or even forking if the main motivation is to resolve trust issues.

[dr-orlovsky]

The base of derive and error/from was written by @elichai because rust bitcoin community would never integrate those two crates you are mentioning (ask Andrew Poelstra and other maintainers why, you can spend months negotiating and writing comments, literally :).

So this code was a part of @elichai's derive_wrapper crate; however I needed more, so made this version which I heavily use in LNP/BP Core Lib. It will take days of my work to change it on any other dependencies, and its not critical at all, so I will not spend my time on it before the first release. Unfortunately I had to move to syn 1.+, so my MSRV version is higher than in rust-bitcoin currently, but in a matter of a year or so it they will match and I hope rust-bitcoin will start using this crate.

[Kixunil]

No problem, I guess I don't know something they know. I don't want to push it more but since I intended to use thiserror for my own security-critical project I'd like to ask @apoelstra to explain/link the reasons for avoiding it. I will not argue it further, and decide for my project on my own. :)

[dr-orlovsky]

1. The s! macro.
   It is useful when you initialize structs having Strings. Not sure whether writing to_string() each time helps newbies. Possible use places: https://github.com/LNP-BP/rust-lnpbp/blob/da2832468b7f021cd8674d2ab2f4138640c10b84/src/bp/chain.rs#L222-L357 Plenties of to_strings() and I do not see how to reformat without them.
2. (b)map! and (b)set! are really needed with RGB and LNP/BP library where they use to initialize structs heavily using BTreeMap and BTreeSet
3. Linked lists were previously used in graph verification operations in RGB over transition history graph, but I refactored it w/o them, so this structure can be removed (however I do not see anything wrong of having it once we already have other collection macro initializers).
4. Never seen InetAddr in stdlib (there are IpAddr and SocketAddr, but no InetAddr). Will be happy to rename, just can't find appropriate name. As for torut, it does not allow the needed functionality of being able to use both IP and Tor addresses in the same structures and being abstracted from which one is used.
5. What do you mean by Futures? Part of the core lib? How we can do it? I assume it will take ages to be merged. But I am ok with trying :)
6. Wrapper is very needed throughout LNP/BP code where each hash type/id needs to be a distingushed type wrapping hash type (and there a lot of them). The same applies for rust-bitcoin; it will be nice to re-factor it with this type + derive instead of all those ugly impl_* macros - the decision was already discussed, but we need to get MSRV bump first (so they will able to use amplify)
7. AsAny is not rarely used at all, it's core requirements for building LNP APIs with marshallers/unmarshallers used throughout all software done at LNP/BP (RGB Node, LNP Node, BP Node, future Bifrost and other servers/daemons):
   https://github.com/LNP-BP/rgb-node/blob/master/src/api/fungible.rs#L25-L53
   https://github.com/LNP-BP/rust-lnpbp/blob/master/src/lnp/presentation/encoding.rs#L32-L42
   https://github.com/LNP-BP/rgb-node/blob/master/src/contracts/fungible/runtime.rs#L173-L191
8. Holder works really good in my cases in LNP/BP Core Library; I use it near hundred of times and it saved plenty of hours of coding time. Hate macros when you can do it without them and increase code maintainability and safety like in these cases:
   https://github.com/LNP-BP/rust-lnpbp/blob/master/src/bp/strict_encoding.rs#L27-L68