Factor out "value" variants of `ConstValue`

[oli-obk]

Basically create a new enum ConstKind which has all the variants of ConstValue except for Scalar, Slice, ByRef. ConstKind should then have a variant (maybe Evaluated or just Value), which contains a ConstValue.

cc #59178 (comment)

continuation of #54738

This is actually just some mechanical refactoring, but also a ton of work (since you'll be touching almost every occurrence of ConstValue).

[RalfJung]

Do you mean Slice instead of ScalarPair?

[oli-obk]

whoops, yea, edited

[stepnivlk]

Hey @oli-obk, happy to take this one :).

[oli-obk]

Awesome! Please do note that this is a ton of work and may get annoying with rebases, so it may require some endurance to get actually merged.

[varkor]

It'd also be better to wait until #59008 is merged, because there's otherwise going to be a lot of conflicts.

[stepnivlk]

@varkor I see, thx for the info.

[yodaldevoid]

@stepnivlk If you did not see, #59008 got merged! Just wanted to ping you in case you are still interested in working on this.

[stepnivlk]

@yodaldevoid great, thx for the info and I actually missed it. I'm def interested, gonna work on that.

[stepnivlk]

hey @oli-obk I have one tiny question, @eddyb mentioned here #59178 (comment) that he wants ConstKind in ty and ConstValue in its current place, is that what we aim for? I'm asking b/c often it's necessary to bring in both ConstKind and ConstValue, mainly for pattern matching. From that perspective those two are quite coupled. I feel like it'd be cleaner to have them both together. What do you think?

[oli-obk]

ConstKind fits better to ty, since that's also where ty::Const is defined. It's perfectly fine that they live in different modules imo. Also, most of the time you won't import ConstKind, but use ty::ConstKind.