Support `ConstArgKind::Path` for uses of `static` paths

[camelid]

Requires allowing constarg -> valtree lowering outside of ctfe. cc #131081

[Keith-Cancel]

I doubt/uncertain this is the best way to handle this since when poking around at other code eval_static_initializer() was not really used like this, so I probably assume it's a hack (unless I am mistaken). Also the below snippet would need more error handling and checks. I was just kinda messing around. So I don't know if it would be useful at all, but figured might as well atleast post it instead of throwing it away.

• Changing the unsupported stub:
  

  rust/compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs

  Lines 2700 to 2702 in 85d0cdf

  	Res::Def(DefKind::Static { .. }, _) => {
  	span_bug!(span, "use of bare `static` ConstArgKind::Path's not yet supported")
  	}

• To the following allows one to do things like Foo<{ STATIC }>.

Res::Def(DefKind::Static { .. }, did) => {
    assert_eq!(opt_self_ty, None);
    let [leading_segments @ .., _] = path.segments else { bug!() };
    let _ = self
        .prohibit_generic_args(leading_segments.iter(), GenericsArgsErrExtend::None);

    let ty = tcx.type_of(did).instantiate_identity();

    let env = ty::TypingEnv::non_body_analysis(tcx, did);
    let lay =
        tcx.layout_of(ty::PseudoCanonicalInput { typing_env: env, value: ty }).unwrap();

    if lay.is_zst() {
        return ty::Const::zero_sized(tcx, ty);
    }

    let val = tcx.eval_static_initializer(did).unwrap();
    let val: ConstAllocation<'_> = val;
    let rng = AllocRange { start: Size::ZERO, size: val.inner().size() };

    if matches!(lay.layout.backend_repr(), BackendRepr::Scalar(_)) {
        let scalar = val.inner().read_scalar(&tcx, rng, false).unwrap();
        return ty::Const::from_bits(
            tcx,
            scalar.to_bits(scalar.size()).unwrap(),
            env,
            ty,
        );
    }
   
    let bytes = val.inner().get_bytes_strip_provenance(&tcx, rng).unwrap();
    let vtree = ty::ValTree::from_raw_bytes(tcx, bytes);
    ty::Const::new_value(tcx, vtree, ty)
    //span_bug!(span, "use of bare `static` ConstArgKind::Path's not yet supported")
}

[BoxyUwU]

Boxy: 132986 was difficult because we couldn't find a nice way to evaluate the static and turn it into valtree
Boxy: ideally we'd want to lower it to a ConstKind::Unevaluated with the static's DefId
Boxy: the problem was that const eval ICEs when you try to const_eval_resolve_for_typeck on static items. I can't quite remember why this is, but that was the problem
Boxy: fixing this probably means doing some ctfe-adjecent/internal refactorinsg to have a way to evaluate a static item to a ValTree for const generics
Boxy: I think for now we should probably error during ast-lowering when lowering a path to a static, and tell people to wrap it in a const block
Boxy: i.e. lower_expr_to_const_arg_direct should call overly_complex_const

The code you've written here is probably not something I''d want to merge for two reasons:

1. HIR ty lowering shouldn't normalize/evaluate things itself. It makes the lowering be lossy which is both a maintenance problem and in some cases can be actually problematic (though I think in this case it isnt)
2. We don't want to maintain a second set of logic for converting const allocations to valtrees, we should really be using the machinery which already exists for const_eval_resolve_for_typeck

If you'd want to file a PR updating ast-lowering to error instead of ICEing that would be great though