Fix output_ordering of WindowAggExec

[mustafasrepo]

Describe the bug

output_ordering method of WindowAggExec gives output ordering of its input, as in the link. Although conceptually it is the correct behavior, SortExec is added before the WindowAggExec during BasicEnforcement pass of the PhysicalOptimizerRule (relevant section). Hence if we inquire the output_ordering of the WindowAggExec before SortExec is added, we will get wrong orderings.

To Reproduce

N.A

Expected behavior

I expect to get true output ordering for WindowAggExec during physical plan construction (before optimizations are applied)

Additional context

N.A

[mingmwang]

WindowAggExec does not change the ordering of the input. If you make a call to output_ordering() method before
the BasicEnforcement pass, it just reflect the facts that the output ordering is the same as its input.
As I explained in the PR, we should not mix the required ordering with the real ordering, they are not always the same.

If you check the other physical operators implementation, the output_ordering() method should return:

1. Return Non if the operator can not keep any ordering.
2. Return the input ordering if the operator can keep the input ordering unchanged.
3. Return some Exprs, if the operator itself can reorder the stream batches, for example SortExec.