Extract abstract base classes from pools and pool ref stores

[simonvoelcker]

This is preparation for the introduction of a new subclass for steam boiler pools.

There was a lot of duplicated code between the three existing types of pools and their respective references stores, with just a bit of drift.

[simonvoelcker]

@Marenz could you have another look please? 🙃

[llucax]

Pretty nice! 🎉

The main concern is the breaking changes. If we decide to add any, we would need to update the release notes to mention it too. Maybe adding tests for the parts that didn't fail even if we introduced breaking changes would be a good idea too.

I'm not completely against a "Address PR comments" commit but since amending the previous commit should be trivial, I would go with that. Also "Make AbstractPool generic over ref store and report types. Extract abstract base class for reports." feels like maybe the second part should be the commit body instead of part of a (long) title?

Finally I wonder if something like ComponentPool could make more sense than AbstractPool, thinking about maybe at some point we want to use them more generically, maybe some lib can accept any pool, not really caring about which kind of components are in it, and just wants to propose power, maybe ComponentPool reads more easily than AbstractPool. Or if we really want to highlight the abtractness, maybe use AbstractComponentPool?

[llucax]

Damn, I just realized batteries_id is an argument for the reference pool, not the battery pool (I always think the pool should be constructed passing the IDs 😱).

Since reference stores are private (not part of the public modules), we don't actually need the deprecation path, we can just rename it (so we can remove the override for the ctor).

Sorry I didn't realized this before 😬

Besides these very minor comments, this is good to go for me.

[llucax]

LGTM, removing the protocol, if possible, is optional and low-prio IMHO, so approving.