Move signal smoothing into the firmware

[ethanjli]

This PR:

• Addresses part of #322 by moving the signal smoothing logic from the frontend to the firmware, so that the firmware performs smoothing on the sensor measurements before sending those measurements to the backend, and making breathing circuit alarms check the smoothed measurements. This should reduce bouncing of alarms, but I have found in testing that it doesn't fully suppress bouncing - a separate alarm debouncing class is needed for that, and that will have to be done in v0.11. In the future, the firmware may need to also send unsmoothed values to the backend for plotting; however, the data sent for plotting may be sent in a different protobuf message format (e.g. a single message containing multiple unsmoothed. SensorMeasurements sampled every 3 ms, while the overall message is only sent every 30 ms), so we shouldn't worry about it for now.
• Removes the signal smoothing code from the frontend, which greatly simplifies the frontend reducer code.
• Adds a sensor_measurements_raw member to the firmware's store, which is only used internally by the firmware - that's where the other drivers output their sensor measurements, and it's used as input to the signal smoother in the firmware. The signal smoother now outputs to the sensor_measurements member in the firmware's store. The store's accessor methods have been renamed to sensor_measurements_raw and sensor_measurements_filtered to avoid confusion in the public interface of the store.
• Adds pseudo-random number generation into the firmware simulator, to add noise to the simulated signals. @rohanpurohit You can look at what I did in Simulator.cpp if you want to add pseudo-randomness to your firmware power management simulator.
• Fixes the HFNCControlLoop to not overwrite simulated flow values if the flow sensors are disabled. @rohanpurohit Now if you run the firmware while the SFM3019 sensors are disabled, the frontend should actually show the simulated flow value.

This PR does not:

• Implement signal smoothing in the simulator backend. We could do this but I'm not sure yet whether it's worth the effort. Maybe after I implement alarm debouncing in the firmware and backend for the breathing circuit alarms, if the alarm still bounces too much in the backend simulator, I could port signal smoothing to the simulator backend.
• Implement actual alarm debouncing functionality - it only smooths the measurements used to trigger alarms, which adds a bit of debouncing for continuous measurements but not for discrete states, and does not fully debounce the alarms on continuous measurements. "Basic alarm debouncing" was listed as the goal for v0.10, but I finished the port of signal smoothing code before I realized that was a different task. We'll have to do "basic alarm debouncing" in a separate PR for v0.11.

@rohanpurohit If you can't test the firmware with a Nonin OEM III sensor connected to measure your SpO2 and HR (the Nonin sensor gives noisy values which fluctuate a lot), I would suggest playing around with the parameters in BreathingCircuit/SignalSmoothing.h for the ConvergenceSmoother to understand how they affect the smoothing behavior, as a way of testing my code using the firmware's noisy simulated values. For now, it should be fine to ignore the ewma_responsiveness parameter because I've currently set that parameter to 1 to disable exponential-weighted moving average, as we'll need to tune that parameter for FiO2 and Flow in an actual ventilator.

[rohanpurohit]

@ethanjli I have fixed the test cases in this branch hotfix/firmware-test-messages, I will test and review soon.

[ethanjli]

For records-keeping:

1. This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes
2. Were any of these contributions also part of work you did for an employer or a client? No
3. Does this work include, or is it based on, any third-party work which you did not create? No