add FilterRejectUnstable implementations

[hizani]

This PR adds a new FilterRejectUnstable function to both the mutable and lo packages. Benchmarks show that the mutable implementation is 7–10x faster than the original lo.FilterReject on my machine.

I understand that introducing an unstable version is a controversial choice, but I couldn’t come up with a similarly efficient stable implementation (at least not as clean as this one). The performance gain justifies this approach for me.

---

I first implemented only an in‑place version in the mutable package but then I realized that this approach could also be useful in the lo package. Although its speed is not much faster than the original FilterReject, it cuts memory usage in half compared to the original implementation, which makes it especially helpful for large collections.

[hizani]

In defense of this solution I can say that in my tasks it often doesn’t matter in what order the function returns the results. I believe there are as many cases where order doesn't matter as there are cases that require stable implementation.