Add TypeId methods variants fields field for type_info

[SpriteOvO]

Tracking issue #146922

• Adds fn TypeId::variants returns the number of variants, for struct and union and primitive types, it's always 1.
• Adds fn TypeId::fields returns the number of fields.
• Adds fn TypeId::field returns a field representing type FieldId.
• Adds a new type FieldId, which is a wrapper of TypeId for fields.

For methods {fields,field}, if indexing out of bounds, a compile-time error will be raised.

Regarding the removal of Type items, this will be done in a later PR in one go.

r? @oli-obk

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The reflection data structures are tied exactly to the implementation
in the compiler. Make sure to also adjust rustc_const_eval/src/const_eval/type_info.rs

cc @oli-obk

[fbstj]

are these indexes affected by specified descriminants? ie does enum Descr { Five = 5 } have a variant_index = 5 ?

View changes since the review

[bjorn3]

Inside the compiler variant index refers to the lexical order of variants. So Descr::Five would have variant index 0. Should probably be documented here though.

[SpriteOvO]

I'll update the doc later. But this is indeed worth mentioning for SemVer and privacy. If we use the current "index" term, then reordering enum variants or struct fields will result in different reflection results.

[oli-obk]

Which may be entirely intentional. Proc macros also use source order. If you want sth else you need to sort by another key.

An alternative would be to provide fields and variants by a sorted list of names and require getting their info by names. Idk if that gets us into trouble with macros defining equal field names with different hygiene, but I hope we just error on that

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.