improper_ctypes is many clippy lints in 1~2 rustc lints

[workingjubilee]

In general, rustc lints are held to a standard of "low false positives". Sometimes they may be opinionated (e.g. all the style lints), but they should generally at least be correct about what they are linting on. Unfortunately, the improper_ctypes lint is a grab-bag of opinions, but few of them necessarily reflect the actuality of what safe FFI looks like, partly because Rust's in-compiler understanding of C ABIs is actually fairly lacking. They are over-conservative approximations, which must often be responded to with liberal usage of allow(improper_ctypes).

In other words, it's a clippy lint. Probably multiple (it's already split into improper_ctypes_definitions, for instance).

This is not a new concern, considering:

• Dubious improper_ctypes firing on recursive non-local containment? #116831
• improper_ctypes lint triggers on valid #[repr(transparent)] types #115457
• improper_ctypes fails to trigger on invalid repr(transparent) types #116959
• PhantomData<T> doesn't trigger improper_ctypes_definitions lint #94000
• improper_ctypes lint should cover "C" abi function pointer types. #95683
• future-incompat: use of SIMD types aren't gated properly #87438
• improper_ctypes should not suggest reprs that lead to errors #60757

I'm not the only one who has suggested extensively refactoring it:

• Refactor improper_ctypes to separate "UCG questions" from linting decisions #72774

Perhaps the more niche cases that it warns on should be moved to clippy and allowed to bake for... a while. This, admittedly, would be the first case that I know of for casting a lint down instead of lifting it up, but it may be justified.