Round before casting preprocessed traces to integer dtypes

[CodeBlackwell]

Several preprocessors cast their float result straight to an integer dtype with astype(), which truncates toward zero instead of rounding. Over many samples that biases the output (toward zero for centered data, downward otherwise). filter.py already rounds before the same cast — this brings whiten, common_reference and highpass_spatial_filter in line with it. It also drops the offset.astype(dtype) cast in ScaleRecording, which was silently zeroing fractional offsets for integer dtypes.

Added tests covering the integer-rounding paths.

Noticed while looking at #1972; this addresses the integer-cast rounding, not the zscore/int_scale std question in that issue.

[zm711]

We've been discussing this a bit and two questions:

1. we aren't sure if we see much value in the tests that were added. We trust the implementation of round vs int from numpy and python. At minimum we would remove the monkey patching test.
2. Could you give us some profiling of this change. We've actually had a discussion about rounding in the past, but the issue is that np.round needs to allocate at least an equalize sized array and we are concerned that even with our chunking mechanism that the memory costs may really explode as recording files are between 10GB-1TB depending on when the memory is freed.