Remove `GroupsAccumulator::supports_convert_to_state` and make `convert_to_state` mandatory

[alamb]

Is your feature request related to a problem or challenge?

Noticed while reviewing this PR from @2010YOUY01

• refactor(hash-aggr): Use EmitTo to output #23055

GroupsAccumulator currently has two related APIs:

• convert_to_state(...), which converts raw input rows directly into intermediate aggregate state
• supports_convert_to_state(), which lets hash aggregate decide whether the skip-partial-aggregation optimization is available

This optional capability adds branching and complexity in the group hash implementation (as the code has to handle the case when skip partial is not available)

It also means GroupsAccumulator implementations can silently miss the high-cardinality fast path.

I believe the original reason for this API was to allow incremental rollout of partial aggregate support (so we could introduce the API and then incrementally implement it for the accumulators)

Describe the solution you'd like

1. Make convert_to_state(...) a required part of the GroupsAccumulator
2. remove supports_convert_to_state()
3. simplify hash aggregate so skip-partial aggregation no longer needs to check per-accumulator support.

Suggested Steps:

• Audit all GroupsAccumulator implementations and ensure each has a correct convert_to_state(...)
• Remove the default not_impl implementation of convert_to_state(...) from datafusion/expr-common/src/groups_accumulator.rs
• Remove GroupsAccumulator::supports_convert_to_state
• Remove skip-aggregation support checks from hash aggregate code, such as the current row_hash.rs guard
• Update FFI groups accumulator support, currently mirrored via FFI_GroupsAccumulator::supports_convert_to_state

Acceptance criteria:

• No supports_convert_to_state API remains
• Upgrading guide explains the required change for external GroupsAccumulator implementors

Describe alternatives you've considered

We could keep supports_convert_to_state() and continue enabling skip-partial aggregation only when all accumulators opt in. That preserves compatibility, but it keeps the hash aggregate code more complex and allows some accumulators to miss the high-cardinality fast path indefinitely.

Additional context

This is likely a breaking public API change for custom aggregate authors and FFI users, so it should be marked as an API change and documented in the upgrading guide.