Reverse and incremental index sorting optimizations

[katzyn]

1. Indexes can now be scanned in reverse order. With these changes both ascending and descending indexes on the same column aren't needed any more for index sorting optimization, only one index is enough. Closes An available index is never used for ordering, when the requested order is DESC #701. Some limitations still exist. For nullable columns ASC NULLS FIRST index can be used for ASC NULLS FIRST and DESC NULLS LAST, but it cannot be used for ASC NULLS LAST or DESC NULLS FIRST. A multi-column index can be used for the same multi-column ORDER BY only if all column are specified with the same order as in the index, or all columns are specified in reverse order. Due to (2) some indexes where not all columns have the same order can still be used.
2. Index that covers only first one or few columns from the ORDER BY clause now may still be used for sorting with an index. It is important for queries with the FETCH clause, because such queries can stop their execution earlier. We need to read additional rows only until a change in the matched indexed columns, all remaining rows aren't needed. This is similar to existing optimization for WITH TIES clause.
3. An old bug with ORDER BY _ROWID_ DESC is fixed, now it really returns rows in descending order.