[FIX] Dllk: Reimplement handling of PRes in transition DLL_CT4

in state DLL_CS_WAIT_SOC as specified in EPSG 301.

This covers the following situations on CN implementations:
1. Just one SoC from MN is lost, because of EMI for example. So the next
   cycle starts with a PRes instead of SoC.
2. Multiple SoCs and the frames in between were lost, because of short
   cable disconnect for example (but frame timeout didn't occur yet). So
   the next cycle which is received by MN starts with a PRes.
3. A late PRes from another CN is received (PRes between SoA and SoC). On
   this CN this is handled as a loss of SoC, but the next SoC isn't
   actually lost. There is just a wrong PRes on the network.

The latter situation might be the reason why the PRes case has been
commented since the early versions of this stack. Why should one CN care
about mistakes of another CN? The answer is that the POWERLINK network
shall provide a deterministic real-time communication and errors must not
remain undetected.

Futhermore, with this fix we indirectly catch the case that an
openPOWERLINK MN (without further hardware support like frame timestamps)
cannot detect late PRes after the SoA. Now another CN would increment its
Loss-of-SoC error counter and force it to go back to PreOp1 when the
threshold is exceeded. For the user the root cause of this error is a
little bit hard to detect, but the error is unveiled (if there are at least
too CNs in the network).

Signed-off-by: Daniel Krueger <daniel.krueger@systec-electronic.com>