Implement cov, corr, rolling_cov, rolling_corr

[Sicheng-Pan]

#204

[sorhawell]

Thank you for implementing these. We should avoid using extendr-internal conversion via &Expr as it will bypass our own conversions, not throw an RPolarsErr and will accept fewer valid inputs. See also explanation here.

robj_to! is currently the way. extendr does not support custom internal conversions. Alternatives are generic trait wrappers or a macro like robj_to!. See some examples here

My aim is to centralize what it means to take a type like Expr as input into one place. If we handle type check ad-hoc in various R or rust snippets, we risk to deviate in behavior and rules for input args. Sometimes we have to, and that is ok.
Currently the central definition converting into Expr is pl$lit and pl$col called via robj_to! where possible.

...otherwise when robj_to! rarely is not possible, you can use wrap_e result & unwrap with on R side.
result and unwrap is used to catch the conversion error and blame pl$cov

pl$cov = function(a,b) {
  result(
    pl_cov(wrap_e(a,str_as_lit = FALSE),wrap_e(b, str_as_lit = FALSE))
  ) |> unwrap("in pl_cov")
}

Now robj_to!(Expr) calls R function pl$lit() and robj_to!(ExprCol) calls R function pl$col().
In a future R function pl$lit and pl$col could derived from robj_to! via pure rust code. That could be cleaner and faster. However query generation is already plenty fast and it would make the code base harder to read for those who are not very comfortable with rust.

[sorhawell]

add unit test which compares to equivalents in R see e.g. "pl$std pl$var" -test . You may use something from data.table to test expected rolling behavior. It is not uncommon there is a difference in behavior. If it is a bug in rust-polars (it happens) we can write a PR to them, or otherwise explain in docs when/why polars is behaving different than plain R.

[sorhawell]

Looks very good to me. Many thanks :)