[CH-186] Support RangePartitioning

[lgbo-ustc]

What changes were proposed in this pull request?

Implement a new NativePartitioning to support RangePartitioning.

what cases are supported

-- simple case
select * from t order by x;

-- mulit cols
select * from t order by x, y desc;

-- order by expressions
select * from t order by x + 1;

don't support order by a complex data type.

in case the backend has functions incompleted, supply option spark.gluten.sql.columnar.rangepartitioning to disable this columnar range partitioning.

How was this patch tested?

unit tests

(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)
test by CH[[189]]

[github-actions]

Thanks for opening a pull request!

Could you open an issue for this pull request on Github Issues?

https://github.com/oap-project/gluten/issues

Then could you also rename commit message and pull request title in the following format?

[Gluten-${ISSUES_ID}] ${detailed message}

See also:

• Other pull requests

[zzcclp]

retest this please

[lgbo-ustc]

There is something wrong under aqe

[lgbo-ustc]

I disable running range partitioning in backend when it has complex expressions in the ordering keys.
1. there are more works to do in the backend to support calculate complex expressions in range partitioning
2. when enable AQE, adding projections for range partitioning shuffle brings some problems. But if don't do so, the expressions will be caculated twice in sort and range partitioning

Build a projection node and pass it to the native splitter, the native splitter will compute the expressions now.
This is may cause the expressions computed twice in sort and range partitioning, but we are not sure which overhead is higher that we compute the expressions twice or transfer results over the network.