Add fast implementation for small window sizes

[Firionus]

See the R/C implementation of runmed for reference

The Stuetzle implementation for small windows can be found at https://github.com/SurajGupta/r-source/blob/a28e609e72ed7c47f6ddfbb86c85279a0750f0b7/src/library/stats/src/Srunmed.c

ToDo

• [x] Initial implementation with Stuetzle-like searching for updated median or lower/upper (see branch smallwin_v2)
• [x] Change partialsort-calls to pivot counting
• [x] Refactor Pivot Counting more clearly
• [ ] Create higher level API that iterates over array
• [ ] Fuzz tests like for double heap (including things like rand(1:2) or rand(1:3) with different window sizes like 1, 2, 3, 4, 5, ... to test for certain edge cases)
• [ ] Benchmark against SortFilters, our own ArrayFilter implementation (?), SkipList implementation (?), DoubleHeap implementation, R implementation (see #20)
• [ ] Formulize pivot counting approach mathematically and explain algorithm better
  • Example: To be a valid median, certain counting conditions (formulate nicely) need to hold. If they don't, the next smaller/bigger element is the new median.
• [ ] Bind into existing high level API (without breaking it)
  • Use something like method = PivotCounting() and PivotCounting <: RunningMedianAlgorithm. This is how DifferentialEquations does it (https://diffeq.sciml.ai/stable/basics/common_solver_opts/#solver_options)
• [ ] Whole lot of QA stuff, Refactoring

[Firionus]

Or could it be an option to call into SortFilters for small window sizes?

This definitely needs a new round of benchmarks, maybe even in CI.

[Firionus]

Or could it be an option to call into SortFilters for small window sizes?

This definitely needs a new round of benchmarks, maybe even in CI.

The initial implementation for rolling with odd window size with pivot counting (benchmarks and code private right now) is more than twice as fast as SortFilters. Calling into SortFilters does not seem like a good idea.