Feat: effector with conductor

[snowyu]

Issue: #638

Due to the immediate changes made by the conductor, while the effector is lagged and executed in a queue, the conductor must always swap_node_force to avoid an infinite loop.

The best solution is to refactor the effector and conductor code to allow for power transmission to also be executed in a queue. In my opinion, the conductor is a special type of effector and should not be treated differently. The conductor should be derived from the abstract effector class, and its default action should be to check and swap_node.

[Desour]

The best solution is to refactor the effector and conductor code to allow for power transmission to also be executed in a queue. In my opinion, the conductor is a special type of effector and should not be treated differently. The conductor should be derived from the abstract effector class, and its default action should be to check and swap_node.

There are builds that require to have instantaneous conductors. And idk how you could avoid infinite loops.
Imo, the mechanics of conductors should not be changed in such a way.

---

Code has some style issues. I.e. mesecons doesn't usually use camelCase.

---

Doing things like checking if it's a conductor, and then doing things with the node as effector, doesn't make much sense to me.

---

It is important that the effector part of a node is only triggered if the signal comes via an effector rule, and that the conductor part is only used if the signal comes via a conductor rule. It doesn't look like the PR does this.

---

If someone wants to have a conductor, that also does something else when it changes state, they can copy the conductor's rules to their effector rules.

---

I should've given feedback earlier, sry.
If you don't want to work on this anymore, I might pick this up sooner or later (or much later).