NTH_VALUE reverse support

[mustafasrepo]

Which issue does this PR close?

Closes #.

Rationale for this change

Currently we cannot calculate NTH_VALUE result in reverse order. However, this can be done, if we were to support negative index for NTH_VALUE (as in python arrays). With this support we can calculate reverse representation of NTH_VALUE to better optimize some plans. Please note that negative index cannot be entered from the SQL query. In this sense, there is no difference from the user point of view.
However, query below

SELECT c, NTH_VALUE(c, 2) OVER(order by c DESC RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as nv1
  FROM multiple_ordered_table
  ORDER BY c ASC
  LIMIT 5

where multiple_ordered_table satisfied c ASC ordering, is re-written as the following behind the scenes

SELECT c, NTH_VALUE(c, -2) OVER(order by c ASC RANGE BETWEEN CURRENT ROW and UNBOUNDED FOLLOWING) as nv1
  FROM multiple_ordered_table
  ORDER BY c ASC
  LIMIT 5

which can be executed without introducing any SortExec to the plan.
For window frame reversal see Constructing Equivalent Window Frames for Reverse Expressions section in the blog post.

What changes are included in this PR?

This PR add negative index support to the NTH_VALUE window function to support reverse order execution.

Are these changes tested?

Yes.

Are there any user-facing changes?

[alamb]

Thanks @mustafasrepo -- the basic code looks good to me but the tests are a little confusing to me

One thing I wonder is why not just allow negative argument to NTH_VALUE from SQL ? If you did that I think the tests would get much simpler / easier

[alamb]

why not change this API to accept i64? It seems strange that the public interface doesn't support negative NTH valuess

[mustafasrepo]

Postgre doesn't have this feature. I thought it might be non-standard or unexpected. However we can this support in subsequent PRs.

[alamb]

Could you please leave a comment explaining what this is a test for (specifically that you are expecting that the nth value should be negative)?

Also I can't see a negative nth value in the plan so maybe I am missing something

[mustafasrepo]

Sure added a comment. However, since window expression names are string, without string manipulation it is not easy to reflect window reversal in the plan. However, I think we should do this absolutely. I will fix this problem in subsequent PRs.

[alamb]

Looks good to me -- thank you @mustafasrepo