Refactor improper_ctypes to separate "UCG questions" from linting decisions

[hanna-kruppe]

(Elaborating on #66220 (comment))

I think that the current state of improper_ctypes is difficult to maintain and extend -- especially once we add more lints that are similar but distinct -- because it's a big pile of mud that interleaving several different concerns: UCG-ish questions about ABI and layout guarantees, plus value judgements about how these interact with "proper" FFI, plus diagnostics code and suggestions. I imagine (but have not worked out the details) that we could improve this by separating this code into two "layers":

• A module (some queries?) answering clean-cut spec questions such as: does this type have a defined memory layout? Defined ABI? If not, why not? etc.
• Several lints that use the facts from that module as basis for emitting warnings, depending on what the lint is targeted at.

I think such an organization would make it clearer what are the language-level guarantees are (including making it easier to audit and evolve) vs what's just a choice or limitation of some lint. More importantly, it would also enable us to implement (without lots of duplication and without making the visitor even more of a big ball of mud) a broader variety of lints that need similar information. For example:

• linting transmutes of types with unspecified layout ([WIP] Impl a more strict transmute check #51294, Warn and eventually forbid transmute::<T, U> for T or U with unspecified (Rust) layout #50842)
• separate lints for "ABI is FFI-safe" vs "C code could actually work with this type" independent of extern imports vs definitions
• lints for type punning via unions (the const alternative to transmute)
• a more opinionated version of improper_ctypes that e.g. prohibits references (due to their aliasing implications which are rarely appropriate in FFI)

[workingjubilee]

from @RalfJung in #130628

The logic here now does not quite match what has been FCP'd, so the lint will fire on some cases where it doesn't have to fire -- specifically if the "other" variant (the one that does not contain the non-null type) has more than one field but all fields are stably 1-ZST.

This PR can land without fixing that though, it just means the lint can be improved, but that's already well-established. ;)

(I also find is_niche_optimization_candidate a very confusing name for "test if this is a 1-ZST and will remain a 1-ZST under semver updates". This type doesn't even have any niches... at least the function has a doc comment clearly describing what it does.)