GCI: During reachability analysis don't try to evaluate the initializer of overly generic free const items

[fmease]

We generally don't want the initializer of free const items to get evaluated if they have any non-lifetime generic parameters. However, while I did account for that in HIR analysis & mono item collection (#136168 & #136429), I didn't account for reachability analysis so far which means that on main we still evaluate such items if they are public for example.

The closed PR #142293 from a year ago did address that as a byproduct but of course it wasn't merged since its primary goal was misguided. This PR extracts & improves upon the relevant parts of that PR which are necessary to fix said issue.

Follow up to #136168 & #136429.
Partially supersedes #142293.
Part of #113521.

r? @BoxyUwU

[rustbot]

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

[fmease]

Going off on a tangent, the whole "don't eval the initializer for non-lifetime-parametric free const items" thing doesn't apply to mGCA's type-level consts which I'm pretty sure is very intentional (IINM) and thus fine, it's also not GCI-specific, e.g., trait T { type const K: usize = const { panic!(); }; } (Self in scope).

I'm only concerned about const items with bodies anyway since the whole idea is to prevent const eval's "bespoke" handling of "too generic" consts "being user observable" / load-bearing for program correctness (the other motivation being consts should behave like fns in this specific scenario) or rephrased "type based" > "value based".