Allow loads / generators to be disconnected without a game over

[DEUCE1957]

Feature Request

By default an episode in Grid2Op will terminate if one of the following conditions is met:

1. The agent reaches the end of the scenario (no more data => scenario ends)
2. A load or a generator (or a storage if the agent tells it to produce or absorbs something) is disconnected from the grid
3. The grid is not "connected", it is split in two. This includes the fact that a load or a generator is alone on a busbar, for example
4. The re-dispatching routine "diverges": this means that grid2op is not able to find a setpoint for the generators for which the 'pmin', 'pmax' and ramping constraints are satisfied to satisfy the balance between demand and generation (sum of loads = sum of generation (plus storage and losses))
5. The solver "diverges" and is not able to compute the next state (often meaning there are no feasible solutions to the Kirchhoff's laws)

In order to explore options like load shedding and generation shedding, it should be possible to loosen condition (2). Implementing this may also make it possible to perform demand side management.

ToDo List

• Modify redispatching routine to take load/generation shedding into account
• Modify action class to add a new type of action
• Modify observation class so that the agent is aware when load / generation is disconnected
• Modify the "next_grid_state" function (or a similar name) so that it takes that into account
• Modify PandaPower backend and lightsim2grid backend so that they keep going if a load / generator is disconnected
• Update documentation in modified code
• Add unit tests to confirm sound behaviour
• Update BackEnd Error to no longer suggest setting production to 0 instead of disconnecting a generator

[DEUCE1957]

For now, as suggested by the BackEnd eerror when you try to disconnect a generator or a load, my workaround is to set the load and generation chronics to 0 in the episode.
Since the ramping rate will prevent this from being done via actions, it is safer and clearer to modify the chronics directly (on disk).
For lines we can use built-in maintenance to turn them off (and keep them off) TODO
For energy storage we can set_status = -1 without causing a game over.