Compute corr, the covariances and regr_* in the steps of PostgreSQL

[tamnd]

Part of #2492.

PostgreSQL computes corr, covar_pop, covar_samp and the regr_* family (except regr_count) from the state of float8_regr_accum. The state holds the count, the two sums, the sums of squared differences from the means in the steps of Youngs and Cramer, and the common value of each side while every row has the same one. Because of the common value, a sum of squares stays at an exact zero for a constant column, so corr(0.09, g) and regr_slope(g, 0.09) are null. rudb used the pin's state for all sessions and gave NaN there, and corr(g, g) gave 1.0000000000000002 where PostgreSQL gives 1.

The new module rudb-kernels/src/pgregression.rs ports float8_regr_accum, float8_regr_combine and the final functions, with the same overflow errors and the same fallbacks through the square roots and through frexp and ldexp when a product does not fit. In a session with the Postgres aggregate types, the binder gives these calls the names of PostgreSQL's final functions (float8_corr and the others), in the same way that it already does for the variance family. The pin keeps the state of rudb-kernels/src/statistics.rs, so DuckDB behavior does not change.

The tests are four unit tests in the module (constant columns, a split state, overflow, frexp) and the server test a_pair_statistic_of_a_constant_column_is_null_as_postgres, which checks oracle answers for a group and for a window. On the harness the statements score goes from 1866 to 1869 of 2588, and nothing regresses.