Calculate latency, receive uplink RSSI, calculate bandwidth congestion and packet rate

[gemenerik]

Continuation of #480 and #477

:rocket: Features

Introduces a framework for link statistics, enabling the tracking of various metrics, starting with latency measurement.

• LinkStatistics Class: A new class to manage multiple types of link statistics, facilitating the addition of more metrics in the future.
• Latency Measurement: A dedicated Latency class is introduced to send periodic ping requests to the Crazyflie. It calculates the round-trip latency and maintains the 95th percentile (p95) latency over recent measurements.

Refactors link quality callback to contain signal health obj with additional signal health information:

• Uplink RSSI parsed from ack
• Bandwidth congestion calculated using null packet ratio
• Packet rate

:memo: To-do

• [ ] CF link C++ uses a different calculation for link quality, investigate if we can unify this.
• [ ] Need to better integrate #480 and #477, the radio link statistics callback can perhaps be routed into LinkStatistics.
• [x] Review naming for better clarity. Link statistics, link quality, and signal health can be easily confused. Also signal health is not a good name if we integrate things like bandwidth congestion.
• [x] Can integrate #479 into the same signal health format.

The implementation improves the lib's ability to monitor communication quality and lays the groundwork for further enhancements in link statistics.

[gemenerik]

In the last commit, I renamed the SignalHealth class to RadioLinkStatistics to better represent its focus on metrics specific to the radio communication, such as RSSI. This class exists to measure parameters at the driver level, as metrics like congestion require direct access to the radio driver, while latency can be measured through packet exchanges.

I also want to bring up the consideration of feeding data from RadioLinkStatistics into the general LinkStatistics. This approach could enhance user clarity by centralizing all link-related metrics in one place. However, keeping them separate might maintain clearer responsibilities and modularity. This is something we might want to discuss further as we refine the implementation.