Sensor: Add filtering to barometric pressure/altitude readings

[ETSells]

Requester: @ETSells

(Non-developer requests only): Is your feature request related to a problem? Please describe.
Barometric data fluctuates with huge spikes in flight, which makes our barometric altitude readings unreliable.

Describe the solution you'd like
We should find some way to smooth out these fluctuations. Per @Aaryan-Anand, we could consider some kind of moving average for now as it'd be fairly simple to implement. An exponential moving average, in particular, would be very simple.

Consider one in the form EMA_t = BARO_EMA_ALPHA * baro_pres_t + (1 - BARO_EMA_ALPHA) * EMA_t-1

Describe alternatives you've considered
N/A

Additional context
N/A

Points of Contact
Primary POC: @NArmistead
Solution pitched by @Aaryan-Anand
Sensor SME: @ETSells

[ETSells]

In mod/sensor/sensor.c, write a static helper function to filter the barometer data according to the spec above

[ETSells]

1. In the source control tab on VSCode, check out the branch development/appa in the mod submodule
2. Create a new branch off of development/appa named feature/vg/[description-of-change]
3. Write your new function according to the description and specs above
4. Commit your changes to your branch with git commit -m "[message]"
5. Push your changes with git push
6. On Github (https://github.com/SunDevilRocketry/mod), create a pull request into development/appa from your branch feature/vg/[description-of-change], and tag your primary point of contact @NArmistead as a reviewer.
7. Address any comments that he makes. If you would like, you can set up a meeting with him to discuss any of this at any point!

[ETSells]

@NArmistead assigned directly as the scope is creeping

✨the firmware experience✨

[NArmistead]

I think I'd prefer to leave this issue as-is and open a new issue/investigation into a better filter so the scope of this issue stays mostly the same. We should still look into how this will work if we're getting repeat values though

[ETSells]

Heard, works for me. Seems consistent with what @Vibbhav-Gopaal has so far, I think he's got a moving average.

If we're quick, we can get this into v2.6.0, whereas any frequency domain filtering or honestly anything more complex than a moving average might be a tougher sell.