Fix issues in 'momentary2nist' and 'toggle2nist' components

[Sigma1912]

• Both 'momentary2nist' and 'toggle2nist' suffer from a loose pulse_length counter that leads to 'on'-,'off'-signals getting cut short because the counter is not reset properly and counts when idling. Fix: The counter is now reset when the pins are changed and no longer counts when the component is idle.

• 'toggle2nist' can endup being desynchronized when the toggle switch is flipped back and forth very fast. Fix: The input pin state is now compared to the state of the device so a switch position disagreeing with the device state will always trigger a change.

• Both components now verify a succesful change in the device by comparing to the expected state rather than output pin values that change in idle.

• For both components the idle state is now the default branch.

[grandixximo]

state zero-inits to 0, which the code below reads as "OFF pulse pending". If the device is already on at startup with the switch off (ison=1, in=0): both edge branches require state == 2, the wait branch counts to max, then the timeout branch runs forever without re-arming because in_val never changes. Isn't the startup desync then stuck until a double flip of the switch, which is exactly the case the description says is now always corrected? Would a one-shot init fix it (variables zero-init, so invert the flag):

if (!init_done) {
    state = 2;
    old_in_val = in_val;
    init_done = 1;
}

[grandixximo]

Shouldn't this (and the timeout comparison below) use max_pulse_length_val? As written the clamp above never applies (setp max_pulse_length 5 takes effect raw), the pin goes through the getter twice per cycle, and the stashed local is set but never used.

[grandixximo]

With state == 2 at idle, ison_val != state is always true, so pulse_length counts to max once at idle. Harmless since the pulse start resets it, but wouldn't a state < 2 && gate make the intent clearer and match toggle2nist?