feat(semantic): support tuple member access via v.0 syntax (#7608)

[orizi]

Summary

Replaces the concrete_struct_id + member fields on ExprMemberAccess with a unified type_member: TypeMember field, and extends member access expressions to support tuple element access via numeric literal syntax (e.g., t.0, t.1).

In dot_expr, a new ast::Expr::Literal branch parses the numeric index, converts it to a member name string, and routes it through the refactored member_access_expr_by_name. The member_access_expr function is split into a name-resolution entry point and a new member_access_expr_by_name helper that handles both struct members (TypeMemberKind::StructMember) and tuple elements (TypeMemberKind::TupleElement).

The lowering and constant evaluation layers are updated to dispatch on TypeMemberKind — struct members look up the concrete struct's member list to find the index, while tuple elements use the index directly from TypeMemberKind::TupleElement.

TypeMember, TypeMemberKind, and Visibility derive Hash to satisfy the new usage in salsa rewrites, and TypeMember/TypeMemberKind are added to the add_expr_rewrites! macro.

---

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

---

Why is this change needed?

Tuple element access via dot notation (e.g., t.0) was previously unsupported — the dot_expr handler would fall through to an InvalidMemberExpression error for any non-path, non-call RHS. The ExprMemberAccess node also hard-coded a struct-specific representation (concrete_struct_id + member), making it impossible to represent tuple element access uniformly in the semantic model.

---

What was the behavior or documentation before?

Writing t.0 on a tuple would produce an InvalidMemberExpression diagnostic. Struct member access in ExprMemberAccess was represented with a ConcreteStructId and MemberId directly on the node.

---

What is the behavior or documentation after?

Tuple element access via numeric literal syntax (e.g., t.0, t.1) is now valid and produces a MemberAccess expression with TypeMemberKind::TupleElement(idx). Struct member access continues to work as before via TypeMemberKind::StructMember(member_id). Both cases are handled uniformly through ExprMemberAccess.type_member.

---

Related issue or discussion (if any)

Resolves the TODO previously noted as #7608 in the code (// TODO(#7608): handle TypeMemberKind::TupleElement here.).

[reviewable-StarkWare]

This change is 

[orizi]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(syntax,semantic,lowering): support tuple struct syntax (struct Foo(T1, T2)) #9885
• feat(semantic): support tuple member access via v.0 syntax (#7608) #9884 👈 (View in Graphite)
• refactor(semantic): introduce TypeMember abstraction for unified struct/tuple member access #9883
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.