ENH: Simpler handling of the ground (earthing)

[alihamdan]

Currently, roseau.load_flow requires the user to create a Ground object and use it in all lines that have shunt components and in ground connections of buses and other elements. This allows the network to have multiple ground elements that are independent of one another. The idea was to allow connections to the ground where these connections would have different electric potentials. In common electrical engineering studies, the connections to the ground are modeled with an impedance and the notion of multiple grounds doesn't exit (to my knowledge). Having different ground connections with potentially different impedances is now possible with the introduction of the GroundConnection class in version 0.12.0. For all these reasons, I think that there is a chance for improving ground handling in the library.

The big improvement in my opinion would be to remove the notion of "ground" and only work with "ground connections". I propose the following changes:

1. Make the ground argument to shunt lines, ground connections, and potential references optional
2. Create a C++ ground object automatically for each network and use it when needed. A ground is needed in the following cases:
   1. A shunt line exists in the network (and no ground is passed to its constructor)
   2. A ground connection exists in the network (and no ground is passed to its constructor)
   3. A potential reference exists in the network that is not connected to a bus (and no ground is passed to its constructor)
3. Add GroundConnection.res_ground_potential to get the potential of the ground similar to Line.res_ground_potential
4. Change the dgs code to no longer create a Ground element
5. Change the documentation and examples.
6. Deprecate:
   1. the rlf.Ground class
   2. the ground argument of the above mentioned elements and their ground attribute if it exists
   3. the grounds argument of the electrical network and deprecate ground related attributes (en.grounds, en.res_grounds, etc.)
7. In one or two releases, remove the deprecated objects and simplify "point 2." above

Advantages:

• easier handling of grounds
• less "uncommon" elements in the library. Uncommon in the sense that they are often not found in other power tools.

Disadantages:

• users will no longer be able to create multiple grounds per network. I can't find any actual use case for them though