Feature channelrouter (sparse matrix, other version of #656)

[PetrGlad]

The branch is based on #656.

Not necessarily for merge but I could not help implementing it, wanted to see how this would look actually. I admit that 'next` looks more verbose, but to me it seems it should be the fastest (especially when most of the coefficients are zero). This can be made even tighter by supporting only smaller number of channels (max of 256 could save 2 bytes on each matrix entry). When channel count changes, this should still keep working, but I'd expect users may want to handle that (or maybe even have several presets for each expected channel count). Also maybe duplicate entries should be rejected - this works just fine but maybe surprising.

There is another idea to consider: the whole matrix is set every time, letting users to modify it any way they see fit. This avoid the problem of keeping track which coefficients are non null or not.

[PetrGlad]

@iluvcapra @dvdsk Can you have a look at this PR? What would you not like in this version?

I think the code is ready. Both versions (this and #656) are functional but one may be better than another depending on context. So I would even consider to have both of them. I stated my preference, though :)

[dvdsk]

I'll have a look 👍 Would you mind postponing the merge of this till #694 lands? Since that is already going to be a monster PR, keeping this off for a while makes #694 easier to write.

[dvdsk]

refactorings + readability stuff

I love that the tests are there they seem to only use the public API so they should work as integration tests.

I wonder about the controller/source split however I think that should be hammered out in #658. Until then we should use rodio's default mechanism (the periodic callback) like in the AGC example

rodio/examples/automatic_gain_control.rs

Line 27 in 8fd0337

let controlled = agc_source.periodic_access(Duration::from_millis(5), move |agc_source| {

We can keep the controller and put that under an experimental flag like with AGC?

[PetrGlad]

@dvdsk This PR is based on #656 to show alternative implementation. So tests are kept from that PR. Generally I tried to keep the API (except for the mixer itself) and tests from that PR intact.

This is not urgent, I just wanted to get some feedback, primarily whether there are any objections against this version compared to one in #656.

[dvdsk]

I have no objections to this version. I think we can keep improving on it but we need benchmarks for that. API-wise there is still a lot to be done. But that would require first hammering out #658.