[fix](agg,array) support TIMESTAMPTZ in multiple aggregate and array …

[Mryange]

…functions (#62756)

#62756

Multiple BE aggregate and array functions failed at runtime when given TIMESTAMPTZ input, despite the FE planner accepting the queries. All failures shared the same root cause: manually maintained primitive-type dispatch switch-cases omitted TYPE_TIMESTAMPTZ.

Affected functions and errors:

Function	Error
max_by(timestamptz, ...) / min_by(timestamptz, ...)	Illegal type TimeStampTz(6) of argument
max_by(..., timestamptz) / min_by(..., timestamptz)	Agg Function max_by(..., timestamptz(6)) is not implemented
map_agg_v2(timestamptz, ...)	Agg Function ... is not implemented
histogram(timestamptz)	Agg Function ... is not implemented
group_array_union(array<timestamptz>)	Agg Function ... is not implemented

aggregate_function_min_max_by.cpp / .h — Replace the large switch-case in both create_max_min_value() and
create_aggregate_function_min_max_by() with
dispatch_switch_scalar(), which covers all scalar types including TYPE_TIMESTAMPTZ automatically. Only non-scalar cases (STRING, ARRAY, BITMAP) are handled separately.

function_array_index.h — Replace the split
dispatch_switch_number() + datetime if-else + IP if-else dispatch in _execute_dispatch() with a single dispatch_switch_scalar() call.

aggregate_function_map_v2.cpp — Add TYPE_TIMESTAMPTZ to the key-type switch.

aggregate_function_histogram.cpp — Add TYPE_TIMESTAMPTZ to creator_with_type_list.

aggregate_function_group_array_set_op_impl.h — Replace the large nested-type switch-case with dispatch_switch_scalar() + is_string_type(), covering all scalar types including TYPE_TIMESTAMPTZ without manual enumeration.

(cherry picked from commit 65e4da4)

What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?