Fixes #3782: Prevent power loops

[hSaria]

Fixes: #3782

Prevent power loops from being created. It ended up being a derivative of the Bellman–Ford algorithm, though it didn't start as one.

Please note that this is not necessarily something we'd want to do; I'm not the expert on power so I don't know if loops inherently exist out there. I created this PR as a potential solution to the ticket, but apart from #3377, it makes no difference if a loop is preset (AFAIK), so it might be worth to continue allowing power loops and just figure out a different way to solve #3377. To be honest, I'd like to keep power loops in case someone needs them.

It runs in a ring-like structure (like the rings on a piece of wood), expanding on every iteration. The ring starts with the source node (i.e. termination_a.device of the new connection). On the second iteration, it will include devices on hop away from those processed in the iteration before. It will stop once all vertices (power cables in this case) that connect to the source node (directly or indirectly) have been scanned, or when a loop gets detected (an iteration containing the destination node termination_b.device).

1st iteration/ring:    A -)- B --- C --- D
2nd iteration/ring:    A --- B -)- C --- D
3rd iteration/ring:    A --- B --- C -)- D

I did my best to in-line document the operation and to keep it as simple as I could, though a cup of coffee when reading it would definitely ease your experience.

Some notes:

• You should probably look at the tests first to understand specifically what this is preventing against.
• Relating to the number of the database operations, this implementation has an upper bound of O(2n), where n is the longest number of hops involving the source node.
• A vertex between the nodes must be of type power outlet; there's an in-line explanation for this (tldr; it is always one end of the cable what would cause a power loop). Because of this and how power is modelled, power feeds improve the search by acting as boundaries.
• Existing power loops will be ignored, but new ones will be prevented.
• Going back to the algorithm, an alternative solution would be to use recursive queries which would have a O(1) time complexity from the perspective of the ORM. However, I didn't go with that implementation because I'm not all too comfortable with it as it'll involve a raw query, but I'm open to refactoring the code to use that instead.

[hSaria]

I'm gonna close this PR as I'm not opposed to it. I'll work on a solution for #3377 instead and make sure it tolerates loops.