dslx: replace NameDefTree with PatternTree

[dank-openai]

Summary

• Replace the NameDefTree wrapper with a PatternTree variant whose leaves are concrete pattern AST nodes.
• Represent parenthesized tuple-pattern syntax with TuplePattern, preserving empty, singleton, trailing-comma, and nested shapes.
• Migrate parser, formatter, cloning, typechecking, exhaustiveness, bytecode, IR conversion, LSP, and fuzzer code to shared PatternTree helpers.
• Reserve retired TypeInfoProto wire value AST_NODE_KIND_NAME_DEF_TREE = 21, add AST_NODE_KIND_TUPLE_PATTERN, and reject legacy value 21 explicitly.

Why This Change

This is the foundational part of the direction requested in the PR #4457 review discussion: remove NameDefTree, make concrete pattern nodes direct PatternTree alternatives, and separate tuple and struct pattern shapes so later struct patterns can also serve ordinary structs. This PR lands only the tuple-pattern foundation used by current DSLX. The StructPattern and nominal/sum-variant pattern work described in that review thread remains in the follow-on semantic-sum PR stack.

NameDefTree currently represents both concrete pattern leaves and parenthesized tuple-pattern structure. That conflates what a pattern is with how tuple nesting is written, which makes later nominal or struct pattern forms awkward to add without more wrapper-specific behavior throughout the compiler.

For example:

let (a, (b, c)) = value;

After this change, the outer and inner parentheses are TuplePattern nodes, while a, b, and c are direct NameDef* alternatives inside PatternTree. A direct binding such as let a = value; remains a direct leaf instead of becoming a one-element wrapper tree.

Compatibility

This intentionally changes the internal C++ AST API: live NameDefTree APIs are removed and all in-repository callers now use PatternTree and TuplePattern. DSLX source behavior is unchanged.

This is backward incompatible for serialized type-info artifacts containing AST kind value 21: decoding now returns an explicit unsupported-legacy error. The old number remains reserved so it cannot be silently reinterpreted as the new tuple-pattern node kind.

Testing

• Focused PatternTree Bazel matrix on Ubuntu 24 covering parser, formatter, cloner, typechecker, type-info proto, exhaustiveness, bytecode, and IR conversion paths
• bazel test //xls/dslx/type_system_v2:typecheck_module_v2_array_tuple_test
• bazel test //xls/dslx/type_system:type_info_to_proto_test

[dank-openai]

@richmckeever One compatibility question for review: this PR keeps AST_NODE_KIND_NAME_DEF_TREE = 21 reserved and rejects serialized type-info entries containing raw value 21, rather than decoding them as the new TuplePattern kind. That makes older type-info artifacts containing NameDefTree entries incompatible.

Is explicit rejection the right boundary here, or should we preserve backward compatibility for those artifacts? If compatibility is needed, what reader behavior should we support without silently interpreting the old wrapper shape as the new tuple-pattern node?

[richmckeever]

@richmckeever One compatibility question for review: this PR keeps AST_NODE_KIND_NAME_DEF_TREE = 21 reserved and rejects serialized type-info entries containing raw value 21, rather than decoding them as the new TuplePattern kind. That makes older type-info artifacts containing NameDefTree entries incompatible.

Is explicit rejection the right boundary here, or should we preserve backward compatibility for those artifacts? If compatibility is needed, what reader behavior should we support without silently interpreting the old wrapper shape as the new tuple-pattern node?

I think we are good with your choice of explicit rejection. To my knowledge, there are no stored serialized records in proto form; only test data files for type_info_to_proto_test which are in the string format.

[dplassgit]

Thanks for the update.