cleanup quasi-layout alignment computations

[workingjubilee]

Originally posted by @scottmcm in #145419 (comment):

I do think that, from an implementation perspective, it's a bit icky for this particular check to do this dance of "fail to get layout, then do extra layout calculations". It feels like there ought to be a general query for "layout but I only care about alignment (or an under- or over-estimate thereof)" that everywhere that doesn't care about things like niches and field offsets, just the alignment, could use so that checks like this would always be consistent. (Like const prop of the Align UnOp in a MIR optimization arguably wants this as well.)

This is a common pattern in cases in the compiler where we want to compute an alignment relative to T. Normally this involves computing the layout of T, but sometimes we don't know exactly what T's layout would be because of some other variable Q which is indeterminate but only affects size, not alignment. So instead we compute the alignment of U, where the question about T's alignment would logically depend on U.

[scottmcm]

This also makes me think of the alignment-and-size niches work, which for cycle avoidance issues wants a "underestimate of size and alignment" query (or similar) that doesn't depend on all the details of exact field layout. Not quite the same thing, though.

EDIT: ZST-ness comes to mind here as well (inspired by https://internals.rust-lang.org/t/allow-impossible-values-of-slice-length-to-be-used-as-enum-discriminant/23933/4?u=scottmcm), where slice niches would get 95% of the value from just a "is it definitely not ZST" query. Similarly, repr(transparent) checks just care about 1-ZST-ness, so don't actually need full layout information in the vast majority of cases.