refactor(rust): unify tuple struct and named struct protocol, and make schema evolution happy

[ariesdevil]

Why?

This PR fixes a schema evolution issue with tuple structs.

Previously, tuple struct fields were sorted by type (same as named structs), which caused schema evolution to break when adding fields of different types.

For example, evolving struct Point(f64, u8) to struct Point(f64, u8, f64) would cause fields to be incorrectly matched during deserialization because the new f64 field would be sorted before u8.

What does this PR do?

1. Introduce SortedField struct: A helper struct that preserves the original field index alongside the field reference. This allows us to correctly track field positions regardless of serialization order.

2. Preserve tuple struct field order: For tuple structs, fields are no longer sorted by type. Instead, they maintain their original definition order ("0", "1", "2", ...). This ensures that field names consistently map to their positions, enabling proper schema evolution.

3. Unify protocol for tuple and named structs: Both tuple structs and named structs now use the same underlying protocol (field name based matching), but with different field name strategies:

   • Named structs: use field identifiers as names (sorted by type for optimal layout)
   • Tuple structs: use positional indices as names (unsorted to preserve schema evolution)

4. Add schema evolution tests: Comprehensive tests for tuple struct schema evolution, including:

   • Adding fields at the end
   • Removing fields from the end
   • Adding fields with different types (i64, u8, f64)

Related issues

Does this PR introduce any user-facing change?
[ ] Does this PR introduce any public API change?
[x] Does this PR introduce any binary protocol compatibility change?
Note: Yes, but since tuple struct support is just supported, I think no one(except me) is using this feature now : )

Benchmark

[ariesdevil]

@chaokunyang Fixed, PTAL again.

[chaokunyang]

LGTM