BUG/ENH: GH10319 added higher_precision argument to rolling_mean/sum
This is not specifically for #10319, but should close it for most cases, should users pass in `higher_precision=True`. #10319 is not really a bug in the Cython code, just precision loss when you do finite-precision arithmetic naively. 

```
>>> sum([0.00012456, 0.0003, -0.00012456, -0.0003])
-5.421010862427522e-20
```

This is `2**-64` and quite negligible, although it can be made much bigger with carefully chosen numbers.  I think rolling_\* functions that require summation could use some more precision, since doing everything in one pass accumulates rounding error, even if the rolling window is narrow.
The only reason why [0.00012456, 0.0003, 0.0, 0.0] currently returns the 'correct' result while [0.00012456, 0.0003, -0.0, -0.0] doesn't is because of explicit negative entry counting. This is only done in rolling_mean but not rolling_sum, and the lack of symmetry doesn't seem desirable. Perhaps we could remove the counting, or add it to rolling_sum as well? 
