Refactor Async UDF rewriting in physical planner

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

#14837 introduced support for async UDFs. As part of it, in the physical planner it rewrites projections, filters (and inputs to aggregations by #17619).

Projection:

https://github.com/apache/datafusion/blob/e323357b1e245d8651183e42747cb92709cb1998/datafusion/core/src/physical_planner.rs#L2244-L2271

Filter:

https://github.com/apache/datafusion/blob/e323357b1e245d8651183e42747cb92709cb1998/datafusion/core/src/physical_planner.rs#L834-L875

Aggregation input:

https://github.com/apache/datafusion/blob/e323357b1e245d8651183e42747cb92709cb1998/datafusion/core/src/physical_planner.rs#L745-L785

I find this quite confusing to understand and it can cause issues (see #18149).

There was also discussion about this in the original async UDF function:
- https://github.com/apache/datafusion/pull/14837#pullrequestreview-2831040913
- https://github.com/apache/datafusion/pull/14837#discussion_r2083479793

### Describe the solution you'd like

Either we try to clean up this rewrite logic and do it earlier, or see if we can design in a way to not need to rewrite at all (see original PR as there seemed to be some discussion towards that direction).

### Describe alternatives you've considered

_No response_

### Additional context

_No response_

Start in datafusion/core/src/physical_planner.rs at the projection, filter, and aggregation-input sections linked in the issue. Read the async UDF implementation in #14837 and the failure context in #18149, then compare whether the rewrite can move earlier or be removed. Done means the planner logic is clearer or avoids rewriting while preserving async UDF behavior and addressing #18149.

Written by the indexing model from the issue text.