Proposal: Decouple 'impact' logic from EDM data model

[JTC-0]

Description

Currently the EDM data model is generated within objects in poopy.py and companies.py. Coupled with this, is some logic to calculate impact - the downstream effects of the discharges and for visualisations.

For users who want to use this package to access data from the APIs and do their own analyses this probably shouldn't require the GDAL dependency for example - which can be a pain to install.

I propose the data model is separated from the impact/visualisation logic so that the dependencies required in the calculation of impact are optional.

This may give:

• Space to grow the impact logic over time to include things like flow, tidal influence etc. without taking away from those wanting only the data model.
• A better logical separation as the data model grows with more companies and the storing of history.

[AlexLipp]

This makes sense to me (with apologies for the long delay). Trying to think about how this would work, we would remove "impact generator" functions as methods of the data classes, and instead make them separate functions that act on WaterCompany objects. e.g., instead of thames.calculate_downstream_impact() we would have: calculate_downstream_impact(thames). The downstream impact functions can come from a separate module, which could be made optional. @JTC-0 do you have experience in making parts of a package optional? As far as implementation goes this shouldn't be too challenging. Thoughts?