arc_with_non_send_sync could indicate why inner type needs to become Send + Sync

Description

warning: usage of an `Arc` that is not `Send` and `Sync`

    = note: `Arc<NiepceApplication>` is not `Send` and `Sync` as:
    = note: - the trait `Send` is not implemented for `NiepceApplication`
    = note: - the trait `Sync` is not implemented for `NiepceApplication`
    = help: consider using an `Rc` instead. `Arc` does not provide benefits for non `Send` and `Sync` types
    = note: if you intend to use `Arc` with `Send` and `Sync` traits
    = note: wrap the inner type with a `Mutex` or implement `Send` and `Sync` for `NiepceApplication`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#arc_with_non_send_sync

The suggestion of using Rc is unhelpful because the intent is really to have Arc.

What would be great is diagnostic info telling me why it isn't Send + Sync by recursively telling me which inner type isn't, and why.

Version

rustc 1.77.1 (7cf61ebde 2024-03-27)
binary: rustc
commit-hash: 7cf61ebde7b22796c69757901dd346d0fe70bd97
commit-date: 2024-03-27
host: x86_64-unknown-linux-gnu
release: 1.77.1
LLVM version: 17.0.6

Additional Labels

No response

Start at the arc_with_non_send_sync lint and inspect how its current diagnostic is produced. Determine how recursive Send and Sync explanations could be represented, then add coverage showing the diagnostic identifies the inner non-Send or non-Sync type and why it fails.