change modeling of OrderingPart to use a sort order instead of a boolean for reversedness

[normen662]

This is related to #1318. It would be useful to state that certain ordering parts are fixed, i.e. bound to one value vie an e.g. equality predicate. In those cases forward and backward become meaningless, they would both fit.

This issue addresses replacing the isReverse with a new enum SortOrder which can be ASCENDING, DESCENDING, and FIXED.

There are some places in the codebase where we reason about Ordering and in particular OrderingParts where we rely on the equality of OrderingParts. An ordering part (q.a, ASC) is equal to (q.a, ASC) only, in particular it is not equal to (q.a, DESC), (q.a, FIXED).

Unfortunately, a RequestedOrdering which is used to enumerate satisfying orderings does not want equality but just compatibility, i.e. a requested ordering of (q.a, ASC) or (q.a, DESC) are both compatible with (q.a, FIXED) even though they are not equal. All of this is part of Ordering.enumerateSatisfyingOrderings() and Ordering.enumerateSatisfyingOrderingComparisonKeyValues().

Similarly, merging two Orderings has a similar problem. An ordering (q.a, ASC) and an ordering (q.a, FIXED) should be merged to (q.a, ASC). The code that needs to be adapted is in Ordering.mergePartialOrderOfOrderings() which (again) only considers equality instead of compatibility.

[alecgrieser]

As a note, having a separate FIXED ordering may help with #2723, though that issue is exacerbated by some other problems with how values are updated during pullUp that we probably want to fix, so maybe we deal with that separately.