restriction lint: `indirect_derive`

What it does

when enabled, this would produce a warning and suggestion whenever referring to a derive macro through a reexport instead of via the original package.

(optionally this would only trigger if the reexport is behind a feature flag, but i'm not sure how feasible that is)

Advantage

Enabling a derive feature flag has a slight overhead on compile times as it linearizes the dependency tree.

For example, building serde with the derive feature enabled means that serde and serde_derive can't be built in parallel.

This is something that often is done internally in the rust project, see https://github.com/rust-lang/rust/pull/141989.
There is currently no automated way to refactor this, as it requires a level of namespace awareness that most (all?) IDEs lack.

Drawbacks

Some library crates may not want their _derive crates to be part of the public API for semver reasons.

May require adding a new entry to Cargo.toml

Example

use serde::Deserialize;

#[derive(Deserialize)]
struct Foo;

...

Could be written as:

use serde::Deserialize;

#[derive(serde_derive::Deserialize)]
struct Foo;
...

No files, tests, or entry points are named. Start by examining how rust-clippy implements existing restriction lints and how Rust resolves derive-macro reexports, then determine whether the proposed warning and suggestion are feasible. Done means the lint reliably distinguishes direct and reexported derives, with tests covering the serde example and any feature-flag behavior.