Inject cerber stores throughout library rather than storing them in an atom

[danielcompton]

Cerber keeps its stores inside atoms. This has some advantages, but makes testing and mocking more difficult as there is only one global store that all tests + the development system reference. As a newcomer to the library, it is also more difficult to work out where side-effects are happening, as the store dependencies aren't explicit. We'd be interested in refactoring cerber to make it less stateful and to inject the stores throughout the library.

I haven't done too much investigation on how difficult this would be to do without breaking backwards compatibility. Before we go any further, I wanted to know what your thoughts are on this idea, and how backwards compatible you'd like to be?

[mbuczko]

I still consider current 2.x version more or less as a playground to figure out the final shape of API and underlaying data model. Also, I would like to move away from boot (somehow abandoned by its creators) towards tools.deps, add PKCE and enhance tests a bit. To sum up, my plan is to stabilize and announce cerber publictly with next release (3.0) which I'm currently developing on develop branch and keep backwards compatibility starting from that point on.

If you feel like stores could be improved (with which btw. I totally agree) I'm happy to discuss it and postpone release to make it easier to include this kind of (non trivial) improvements without worrying much about backwards compatibility, yet :)