Perf: Short circuit expensive comparissions in GroupColumn

[Rich-T-kid]

Which issue does this PR close?

• Closes Short circuit expensive comparissions in GroupColumn trait #23342.

Rationale for this change

see #23342

Note : the exact ranking here is a bit arbitrary & i'm happy to change it. The core idea is that its much cheaper to do boolean checks and fixed size byte comparisons as opposed to chasing pointers to comparing strings.
an alternative approach may be to split this into two tiers:

1. ints/bools/floats/
2. bytes data

What changes are included in this PR?

• Add compare_tier() to rank each supported DataType by comparison cost (1 = cheap fixed-width integers → 5 = expensive variable-length bytes)
• Add compare_order: Vec to GroupValuesColumn, built once at construction via build_group_compare_order(), so vectorized_equal_to evaluates columns cheapest-first and maximizes early-exit savings before reaching expensive string comparisons

Are these changes tested?

This PR only change the order in which comparisons occurs. functionally nothing changes.

Are there any user-facing changes?

no

[Rich-T-kid]

cc @zhuqi-lucas as this is related to #22715
Could a maintainer run the benchmarks?

[RatulDawar]

Shouldn't this belong to a common place as this can be used across other operators like HashJoins

[Rich-T-kid]

I suppose 🤔 , is there a specific case where you think this would be useful for hashJoins?

[RatulDawar]

When JoinKeyComparator finds groups matching groups per row similarly, correct me if I am wrong. Here the compare method can also use this optimized ordering right ?

[Rich-T-kid]

Im honestly not too familiar with the join operator logic. but presumably the same concepts should apply there. Ideally i'd like to move forward with #23342. but I can make a follow up ticket to move this into a higher modules for code re-use