Resolve "Drop support for multiple plane parameters with ForecastSolar for simplicity"

Summary

Currently the user can pass multiple plane parameters to ForecastSolarNode instantiation.

This however might be inconsistent with the idea of nodes as single datapoints. Furthermore the internal implementation by lists, has introduced complexities and might continue to do so.

Dropping support altogether might therefore ensure low error-proneness and consistent use of nodes as unitary datapoints. Correct data aggregation should be implemented in read_series methods.

Explain your context

• removed helper function to unpack possible lists of plane parameters
• refactored code to consider only primitive datatypes
• Adapted and extended affected tests
• New internal grouping mechanism of nodes
• Collected requests
• Data aggregation of nodes at the same location

Please list breaking changes, new features or bugfixes

• Breaking changes:

1. Multiple plane parameters in a single ForecastSolar node not supported anymore
2. If applicable requests initiated by read or read_series are now internally collected into the least amount of requests possible according to the max_plane_count attribute, specified in connection instantiation (defaults to 3).
3. Accordingly all nodes that can be summarised, will be aggregated in data processing
4. ForecastSolarConnection() constructor now takes an additional account_model parameter that ultimately specifies how many nodes can be aggregated together. It defaults to 3 what in turn requires an appropriate API key. We provide 4 class constants:

# Account models
PUBLIC = 1
PERSONAL = 1
PERSONAL_PLUS = 2
PROFESSIONAL = 3
PROFESSIONAL_PLUS = 4

5. Important: Column names of resulting dataframes will therefore not correspond to node.name but instead a location identifier, e.g.

>> nodes = [
..    Node1 = (name=x, lat=51, lon=10, ...),
..    Node2 = (name=y, lat=51, lon=10, ...),
..    Node3 = (name=z, lat=51, lon=10, ...),
.. ]
>> ForecastSolarConnection(max_pool_count=2).read(nodes).columns
coord(51, 10) # Before it would have returned: [x, y, z]

• Bugfixes:

1. Horizon field validation

Closes #311 (closed)