Support for observing intermediate aggregation results

### Is your feature request related to a problem or challenge?

For long-running aggregation queries, users want to observe intermediate results as the query progresses rather than waiting for the final answer. This enables:
- Progress monitoring: Show users that queries are making progress and haven't stalled
- Early insights: Start analyzing partial results before the query completes
- Better UX: Display progressive updates in interactive applications (dashboards, notebooks, Jupyter)
- Approximate query processing: Return "good enough" answers quickly, refine as more data is processed

Other mature query engines provide various mechanisms for observing query progress or returning partial results.

### Describe the solution you'd like

We'd like to explore ways to observe intermediate aggregation state for queries with unordered input, particularly for grouped aggregations.

Some properties that seem important:
- Non-destructive: Observing intermediate state shouldn't affect final results
- Periodic: Ability to check state at intervals (time-based or batch-count-based)
- Efficient: Overhead should be proportional to data observed, not re-processing
- Opt-in: Feature should be optional and not impact queries that don't use it

We've done some preliminary exploration and have ideas. We explored callback-based peeking with a user-facing API like this:

```rust
let peek_config = IntermediatePeekConfig::new(1000, |context: PeekContext| {
// Receive intermediate results as Arrow RecordBatch
handle_intermediate_results(&context.intermediate_batch);
Ok(())
});

let agg_exec = agg_exec.with_intermediate_peek_config(Some(peek_config));
```

And extending existing traits with non-destructive peek methods:

```rust
pub trait GroupValues: Send {
// ... existing methods ...

fn peek(&self, num_groups: usize) -> Result> {
not_impl_err!("peek not supported") // Default implementation
}
}

pub trait GroupsAccumulator: Send {
// ... existing methods ...

fn peek_evaluate(&self, num_groups: usize) -> Result {
not_impl_err!("peek_evaluate not supported") // Default implementation
}
}
```

We're very interested in hearing from the community about:
- Whether this use case resonates with others
- Potential approaches we may have missed
- How this might fit with DataFusion's architecture and future direction
- Whether there are existing extension points we could leverage

### Describe alternatives you've considered

_No response_

### Additional context

We believe this feature would benefit the broader DataFusion community beyond our specific use case (interactive analytics, approximate query processing, debugging). We're looking for:
- Design feedback: Which approach aligns best with DataFusion's architecture?
- API suggestions: Better ways to expose this functionality?
- Alternative approaches: Are there existing mechanisms we've overlooked?
- Collaboration: Would DataFusion maintainers/community be interested in this feature?
- Scope guidance: Should we aim for comprehensive support or start with a minimal viable feature?

If the community sees value in this feature and we can align on an approach, we're willing to invest engineering effort to implement it properly. We'd appreciate guidance from maintainers and looking forward to the discussion!

Begin with the GroupValues and GroupsAccumulator trait definitions and the callback-based IntermediatePeekConfig sketch in this issue. Compare those extension points with DataFusion's grouped aggregation behavior, then narrow the scope and document a maintainer-approved design for non-destructive, periodic observation.

Written by the indexing model from the issue text.