Add #[thiserror(crate = "...")] attribute for re-export scenarios

[suchyj-btlnet]

When a crate re-exports thiserror and exposes a macro that generates #[derive(Error)] types, the consuming crate must still list thiserror as a direct dependency — because the derive unconditionally emits ::thiserror:: absolute paths into the generated code. This makes thiserror a leaky dependency that cannot be fully encapsulated behind a re-export.

This PR adds a #[thiserror(crate = "...")] container attribute, following the same pattern as #[serde(crate = "...")] (serde-rs/serde#1499). When present, all generated paths use the specified crate root instead of ::thiserror.

Repro: https://github.com/suchyj-btlnet/thiserror-reexport-repro — consumer fails to build because it has no direct thiserror dependency.

To validate the fix, clone this PR's branch next to the repro repo, then:

1. Uncomment [patch.crates-io] in the repro's root Cargo.toml
2. Uncomment #[thiserror(crate = "macro_lib::thiserror")] in macro-lib/src/lib.rs
3. cargo build -p consumer now succeeds

To be honest, @dtolnay doesn't prefer this from here #167
however @dtolnay also approved and merged this exact fix in serde (above).

So I hope this PR will get merged to get this functionality also in thiserror

Cheers, Jacob

[dtolnay]

As discussed in the issue, I would prefer not to provide this workaround. Please follow the suggested implementation from #167 (comment).

[suchyj-btlnet]

As discussed in the issue, I would prefer not to provide this workaround. Please follow the suggested implementation from #167 (comment).

Sorry @dtolnay, could you please point me to the suggested workaround?

If you ment #167 (comment) from @alexkirsz, that doesn't work in my repro.
See the image what I tried.

If you ment your comment in rust-lang/rust#54363 (comment) that is not an implemented feature in cargo yet. 😑

Thanks

Edit: Sorry for my lack of knowledge, I'm in rust ecosystem only for 1.5years, I have limited understanding of macros and I don't understand this problem fully.
But braining with an LLM and going deeper with @alexkirsz suggestion.. It seems that his workaround doesn't apply to my use case 😞