Remove Parse::Node, add ElementIndex in docs for typed insts

[danakj]

The documentation still referred to typed instructions having a Parse::Node field, however that was removed and moved to the InstStore in f197219.

Then GetParseNode() was renamed to GetNodeId() in 86a7c9f and then GetLocationId() in b079acd and finally GetLocId() in b5d28f2.

The comment in typed_inst.h mentions only three fields now, but some types still have four, thanks to the unmentioned ElementIndex index field. Normally this field comes last, after the [...]Id fields except for in one case, AssociatedEntity. Rather than write ambiguously ordered documentation, update the comment to and docs to say that the ElementIndex comes last, and move it to the last position in AssociatedEntity. Tests are rebased accordingly.

[danakj]

I know there's some StructReflection which in theory could be made to do the wrong thing by changing field orders, but I couldn't find anything like that affected here, but just in case pointing it out?

[zygoloid]

This is one of the kind-specific members described in the previous bullet, rather than a distinct special case. I don't think it's worth calling out as a special case here, but maybe the previous bullet could mention there are various different valid types for the kind-specific members?

[danakj]

I've combined these two bullet points together, using them as two examples.

[zygoloid]

Maybe we should say: up to two members of types derived from IdBase rather than inaccurately saying `[...]Id`.

[zygoloid]

Though even that's not quite right. IntId and BuiltinInstKind are the exceptions. The real rule is that they need to be listed in the IdKind enum and implement the FromRaw/ToRaw protocol in inst.h.

[danakj]

Ah okay, also there's one type with three IdBase members:

struct AnyAggregateAccess {
  static constexpr InstKind Kinds[] = {
      InstKind::StructAccess, InstKind::TupleAccess,
      InstKind::ClassElementAccess, InstKind::InterfaceWitnessAccess};

  InstKind kind;
  TypeId type_id;
  InstId aggregate_id;
  ElementIndex index;
};```

[danakj]

Ah but one is type_id, okay nvm. This one threw me off but that was because I forgot the type_id rule.

[danakj]

A couple more observations though:

• AnyFoundationDecl and AnyBranch have an int32_t member, rather than something like an ElementIndex. ToRaw(int32_t) does not appear to be defined.
• While IntId is, BuiltinInstKind is not in the IdKind enum. But the latter is also not a field in any typed inst. Rather than having a BuiltinInst typed inst, we now have a separate struct for each one, introduced in be5db6e.
• The idea that builtins don't have a location id comes from the old text around SemIR::Builtin, a type that no longer exists. I can't find a reason why this would be true in the code, the parsing adds a TokenIndex at the location of a builtin instruction that should come with a source location. I am guessing this was maybe referring to the definition of builtins? And that this just no longer exists, as they are proper builtin instructions now? As such I think I would remove that clause and just say all instructions come with a location?

[danakj]

Ok I understand the first two points now, and I think we can make this more explicit in the code and do some cleanup as a result, which I've done in #4606

[danakj]

Thanks!