Rewrite: Implement an event-driven tree-like internal memory structure

[DevilXD]

Ref: #90 (comment)

All of this suggests to me that a tree-like internal structure of campaigns to channels, with some kind of events system propagating changes to each leaf, would be a simpler approach to this "state updating" problem we have here. The current system of loops and triggers telling those loops to re-loop and recheck all conditions works "okay", but does a lot of work unnecessarily, for example, each time a reload happens, all "old" campaigns are just purged from memory, and a new set of campaigns is fetched and processed onto their place. Doing this leads to then having to do the same for all tracked channels, including unsubscribing and resubscribing websocket topics, having to "relink" the watching channel (because the internal object for it changed to a new one), and many other similar things. If none of the campaign's changed anything within the hour between each reload though, none of this would be needed and the miner could just continue on with it's state as-is. Similarly, even if the state would change and a new campaign would be added (for example), normally it'd be just a matter of:

• checking if we have to fetch some new channels for this new campaign
• checking if we need to possibly switch the watching channel

..., and that's it. Existing campaign and channel objects could be retained between reloads, to avoid hammering the RAM and CPU with deleting and readding objects with identical structure and data.

This is a WIP issue, solely for TODO tracking purposes.

v16 tracker: #234