[DISCUSS] Representing Shared State / `ExecutionPlan::reset_state`

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

I brought this out into its own discussion so it wasn't lost on a PR comment

@Dandandan observes on https://github.com/apache/datafusion/pull/21351#discussion_r3086222712:

> I don't like the additions in some recent PRs of reset_state on plans / sources etc.
>
> In my opinion we should avoid setting mutable state on ExecutionPlans (and related data structures) & move that to the inner streams.
>
> In an ideal scenario:
>
> During any time we can clone a plan and share / run it without expecting any side effects (e.g. partially executed plans)
> Concurrent runs of a query (ideallyexecutes) should result in the same result, even while a query is running.
> In my PR https://github.com/apache/datafusion/pull/20481 I combined the shared state using TaskContext (which, in normal usages, will be created on each new query run), which I think still not is 100% the desired end state but avoids a lot of scenario's.
>
> https://github.com/apache/datafusion/pull/20481/files#diff-e3975f93f1d4599fe6f19905e81f02574d65402e604e39c45b87448b3892d1adR70

### Describe the solution you'd like

_No response_

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Start with the ExecutionPlan::reset_state discussion and read the linked PR 21351 comments alongside PR 20481, especially its TaskContext changes. Trace how shared state is represented during concurrent query runs. Done requires an agreed design for plan and stream state, with the relevant behavior covered by tests or documented acceptance criteria.

Written by the indexing model from the issue text.