Refactor analysis processing to reduce script memory footprint

[emontmas]

Improve the sv-timestamp-analysis script to process large amounts of data.

This script's input data is an exhaustive list of timestamps of each IEC 61850 SV packets that were sent by a publisher are received by a subscriber machine during a SEAPATH latency test.
Because a single SV channel sends over 4000 SV packets per second and that data is saved as text, resulting data files can be quite large.
For example the file size for 15 mins of SV data with a single stream is roughly 106 Mb.
With tests of multiple hours (e.g. 5H, 8H, ...), data files would weight multiple Gigabytes.
Moreover, the amount of data is doubled for a SV latency test, as SVs are recorded on both publisher and subscriber sides.

Currently, when the sv-timestamp-analysis script processes these data files, it loads them once entirely in RAM, then process the data. This does not scale well with large volume of data from hours long SV latency tests.
Having a script loading multiple gigabytes of data in RAM isn't desirable.

This PR refactor in-depth the way SV data are read and processed.

• Instead of reading the full SV data (both publisher and subscriber), process by parts / chunks of the input data. That way the script only needs the current chunk of data to be loaded in RAM.
  Chunk boundaries are defined by SV iteration boundaries, as sv drops can only be recovered in a given SV iteration.
• Refactor the way latencies and pacing results are stored.
  Instead of keeping every data point in RAM (e.g. storing 10,000 integers for 150 µs latencies), keep only the total count each latency value happened. (e.g. storing that 150 µs latency happened 10,000, only needs 2 integers).
  The former approach is indeed extremely inefficient for long latency tests. For example, with a 5H long test for a single SV stream, 5*60*60*4,000=72,000,000 SV will be sent and the same number of latencies will be computed.
  Assuming values in microseconds are stored on 64 bits integers (the default for numpy arrays of integers), this would be equivalent to (72,000,000*8) = 576,000,000 bytes ~= 549 Mb, where most of the latencies are equals.
  • Use pandas DataFrame to easily store and increment latencies and pacing counts across chunks of data with a minimal memory footprint.
• Remove unneeded SV data validity check
• Check SV iteration consistency in SV data by reading the end of the files with less, instead of requiring the entire SV data.
• Make various improvements to code and docstring to improve maintainability of the script.

Note that part of this PR temporarily breaks the script while refactoring the processing logic, to allow incrementally adding changes to avoid large commits. But the PR in itself preserve all functionalities of the script.