Use `approx_ty_size` for `large_enum_variant` by lukaslueg · Pull Request #9400...

This builds upon #9373 to use the approximate size of each variant for large_enum_variant. This allows us to lint in situations where an enum contains generics but is still guaranteed to have a large variant on an at-least basis, e.g. with (T, [u8; 512]).

• I've changed the wording from "is ... bytes" to "contains at least" because
  • the size is now an approximate lower bound (e.g. 512 in the example above). The actual size is larger due to T, including due to T's memory layout.
  • the discriminant is not taken into account in the message. This comes up with variants like A(T), which are "is at least 0 bytes" otherwise, which may be misleading.
• If the second-largest variant has no fields, there is a special case "carries no data" instead of "is at least 0 bytes".
• A variant like A(T) is "at least 0 bytes", which is technically true, yet we don't distinguish between "indeterminate" and truly "ZST".
• The generics-tests that were there before now lint while they didn't lint before. AFAICS this is correct.

I guess the above is correct-ish. However, I use the SubstsRef that I got via cx.tcx.type_of(item.def_id) to solve for generics in the variants. Is this even applicable, since we start from an - [ ] ItemKind?

changelog: none