[core] Fixed RCV TL drop of packets dropped by SND

[maxsharabayko]

The receiver buffer may have packets dropped by sender (marked as EntryState_Drop).
In that case, the ACK position is likely ahead of the current reading position. This has to be taken into account in the TSBPD thread.
It can result in the receiver hanging up for a couple of seconds, making the sender break the connection.

1. At some point, the receiver hangs up (for about 12 seconds in total) due to the issue fixed above.
2. Three seconds later the sender detects there is no response from the receiver, and breaks the connection.
3. About ten seconds later receiver wakes up and continues processing incoming packets, that were accumulated in the system buffer of the UDP socket.
4. Because of that stall it receives heavily delayed ACKACK packets. Based on the ACK - ACKACK pair of packets receiver estimates RTT, in this case, extra 10+ seconds are added to the estimation, significantly raising SRTT and RTTVar values.
5. The overestimated SRTT and RTTVar values then impact the connection expiration timeout of SRTT + 4 x RTTVar: it now results in tens of seconds. Therefore, the receiver waits for tens of seconds before concluding the connection with the sender is broken. The SHUTDOWN control packet from the sender is probably lost in that case.

This PR Changes

• CRcvBufferNew::dropUpTo(..) now returns the number of packets actually dropped. This value is used to update the RCV drop statistics.
• The update of m_iRcvLastSkipAck happens only if dropping ahead of the current ACK position. Loss lists update as well.
• Move the TL drop logic into a dedicated function CUDT::dropTooLate(int upTo).
• Fix the documentation on the pktRcvDrop and pktRcvDropTotal.