New lint: No longer supporting `no_std` use

[obi1kenobi]

Some crates (often on only some feature combinations) advertise support for no_std use cases: situations where the Rust standard library components (std, alloc, etc.) are not available and one can only use core.

It's relatively easy to accidentally break no_std support: for example, change an import from core to its equivalent std re-export, like we test for here: https://github.com/obi1kenobi/cargo-semver-checks/pull/892#issuecomment-2364056127

Users with no_std use cases would be broken by such a change. We may be able to lint for this after #638 is resolved. We should consider adding a lint for it then!

Such a lint would have more false-negatives unless rustdoc JSON starts including non-pub use statements when we --document-private-items. This is because a private item may import from std instead of core.

We'd also likely have to read source to make this work, not just rustdoc JSON. This is because rustdoc JSON normalizes import paths for foreign items, so std::fmt::Debug and core::fmt::Debug are both usually presented as core::fmt::Debug in rustdoc JSON.