[FIX]  Reimplement handling of PRes in transition DLL_CT4

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).

Based on change for V1.8.4 by
Daniel Krueger <daniel.krueger@systec-electronic.com>

Change-Id: Ib5f41389bf4d43fd116e17a1256da43ceb92f14e