Fixes to sigproc.Window

[cboulay]

Note - this is based off #62 and requires #62 to be valid. Of the 4 commits (so far), only the 2nd and 3rd are in question, as the first is from the other PR and the 4th is a cherry-pick from another PR that was already merged into main, but not dev (and I need it in dev).

In this PR, I...

• Expanded the sigproc.Window unit tests which revealed a bunch of failures.
  • The expansion to the tests look at the time (or newaxis) .offset values, and the data assuming Counter is correct.
• Refactored sigproc.Window to satisfy the tests.

I also noticed that the initialization of the buffer creates a window-length buffer that's all zeros. Then, when new data comes in, the first window out comes only from the initialized zeros! I highly doubt that we want a completely fabricated window as the first window through the pipeline.

I added a new zero_pad_until setting.

• "full" (default), maintains the current behaviour, though maybe that shouldn't be the default.
• "shift" fills the buffer with zeros except for the space required for a single shift, meaning that the first window out will have exactly a single window-shift's worth of real data.
• "input" fills the buffer with zeros but leaves room for the input. In this mode, the first yielded window will have as much of the input data as possible. IMO this should be the default because it provides minimal latency.
• "none" does not use zero-padding in the buffer. There will not be any windows yielded until we have received enough messages to fill at least 1 windows.

[griffinmilsap]

Agreed the zero padding is suboptimal... I really need one-to-one behavior in some of my pipelines (one input results in one output) in order to track completion of processing, so this was the necessary evil. Nans would have been a better choice for padding here, but would likely break the existing filter implementation.

I'm happy to accept this so long as it maintains current behavior as the default. We can deprecate this as a default with a warning.

[cboulay]

I've completely rewritten this, using the generator pattern and adding way more unit tests.

I'll make this a draft for now while I prepare another PR that my new version depends on, then I'll update this PR.

[cboulay]

Note that a457108 is the same commit as in #79 and it might make sense to look at that one first.