[BUG] [Query Planner] Properly track ascending/descending sort order for range partitioning and sorting.

[clarkzinzow]

This PR ensures that we properly track ascending/descending sort order for range partitioning and sorting ops, to ensure that downstream operations correctly interpret the partition spec.

For example, before this PR, the planner would always assume that if both sides of the join are sorted, then they're sorted in ascending order and could therefore be efficiently joined with our sort-merge join (which currently only does ascending-order sorts/merges); this would lead to incorrect results if either side was sorted in descending order.

Closes #1829

Follow-ups (future PRs)

• Refactor sort-merge join to work for both ascending and descending order; this can be done when porting the Partitioning abstraction to Rust to enable better dtype support.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (573ea12) 85.48% compared to head (5a69358) 85.55%.
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1862      +/-   ##
==========================================
+ Coverage   85.48%   85.55%   +0.06%     
==========================================
  Files          55       55              
  Lines        6147     6194      +47     
==========================================
+ Hits         5255     5299      +44     
- Misses        892      895       +3     

see 9 files with indirect coverage changes

[samster25]

There seems to be redundancy between PartitionSchemeConfig and PartitionScheme. We can probably fold in num_partitions and by to the enum variants that are relevant