[BugFix] Make SQLAlchemy reflection dataclasses hashable

[VijayShekhawat7]

Why I'm doing:

Fixes #70733

The ReflectedTableKeyInfo, ReflectedPartitionInfo, ReflectedDistributionInfo, and ReflectedRefreshInfo dataclasses in the StarRocks Python client lack __hash__ implementations. SQLAlchemy's reflection cache uses these as dict keys, causing TypeError: unhashable type at runtime.

What I'm doing:

Three changes to make all four dataclasses safely hashable:

1. Custom __hash__ for list-column classes: ReflectedTableKeyInfo and ReflectedDistributionInfo have a columns field typed Optional[Union[List[str], str]]. Python's unsafe_hash=True cannot handle List[str] (unhashable type). These classes now define explicit __hash__ methods that convert list-typed columns to tuples before hashing. ReflectedRefreshInfo and ReflectedPartitionInfo keep unsafe_hash=True since all their fields are already hashable types (strings).

2. Non-mutating __str__ methods: The original __str__ methods on ReflectedTableKeyInfo, ReflectedPartitionInfo, and ReflectedDistributionInfo mutated self.type and self.columns in-place (e.g., self.type = self.type.upper()). With hashing enabled, this would cause hash instability — the hash changes after calling str(). Refactored all __str__ methods to use local variables instead.

3. Dead code removal: Removed unused type_str variable in ReflectedPartitionInfo.__str__.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4

[VijayShekhawat7]

Closing in favor of #70734 by @aholowko which addresses the same issue and was submitted earlier. Apologies for the duplicate.