[core] Fixed miscalculations on extreme loss conditions in FEC

[ethouris]

Involved PRs (need to be retested):

• Double free or corruption in FEC #1594
• When FEC is enabled and lots of packets are dropped, it does not recover. #894

General description:

The procedures concerning extreme conditions, like lots of lost packets in a row, resulting in a necessity of removal of some existing parts. There were two general false presumptions:

• At least 2 series of matrices were supposed to exist. In result the removal of one series were presuming that there exist always the next series. The problem is that the groups for incoming packets are created dynamically, as packets come in, while with a lots of packets lost in a row this could result in having lots of packet sequence range not covered by existing FEC groups. For example: the distance between the group base and the incoming packet is 10x the matrix size, however the previously received packet was from series 2. Effectively series from 3 to 10 don't exist, while the removal attempt was for all series but last 2. The false presumption was that these series exist, and that you can read any data from them, at least for example to get the value of the new base sequence - reading was also happening from outside the container.
• Another problem was that the emergency removal was focused only on one type of groups (horizontal or vertical). This was completely wrong - any removal, emergency or not, must be strictly done by one unified function, which simply dismisses whole series of groups and makes sure that all three containers - receiver column queue, receiver row queue and receiver cells - are perfectly in synch, that is, rcv.colq[0].base == rcv.rowq[0].base == rcv.cell_base. Therefore there's one unified function that is called in case of emergency, no matter if triggered from the row or column check, will simply delete all series but last two and will calculate correctly the new base sequence for all containers.