Followup work from making `ValTree` recurse through `ty::Const`

After #149114 ValTree's Branches variant stores a list of ty::Const instead of a list of ValTrees. See the PR description and associated zulip thread (#project-const-generics > Valtrees that can contain generic params) for a motivation for this.

This has left us with two problems:

1. The name Value is kinda confusing :) These are in some sense not full values. It may be desirable to rename ConstKind::Value, ty::Value, ty::ValTree and ty::ValTreeKind to something different now that they don't represent full values.
2. There are now a bunch of extra Ty in a fully evaluate ValTree. This is likely bad for performance. Though more importantly it means that when CTFE evaluates something to a ValTree it has to pick types for all the nested nodes in a ValTree. This is effectively impossible for CTFE to do correctly as it doesn't have lifetime information so we wind up with a bunch of erased lifetimes entering the type system.

The second point can be observed by looking at debug logs for this code example:

#![feature(adt_const_params, unsized_const_params)]
#![expect(incomplete_features)]
#![crate_type = "lib"]

struct Foo<'a> {
    r: &'a u32,
}

fn bar<const N: Foo<'static>>() { }

fn qux() {
    bar::<{ Foo { r: &1 } }>();
}

0ms DEBUG rustc_trait_selection::traits ct=UnevaluatedConst { def: DefId(0:9 ~ foo[cae9]::qux::{constant#0}), args: [] }
0ms DEBUG rustc_trait_selection::traits return=Ok(ValTree(Branch([ValTree(Leaf(0x00000001): &'{erased} u32)]): Foo::<'static>))

Assigning myself as I'm partially through fixing this second point.