Telemetry: Add an HMAC style authentication scheme to the telemetry system

Start by tracing telemetry message generation on the flight computer, transmission over LoRa, and receipt and validation in the ground station/SDEC path. Review the alternative in Flight-Computer-Firmware issue 191 and establish the authentication design, key handling, message-size impact, and invalid-message behavior before implementation. Done means the agreed security measure is integrated across both ends and malformed or unauthenticated data is not propagated.

Requester: @ETSells

Describe the solution you'd like
The ground station currently provides no validation for the data it receives over LoRa. This is a security vulnerability. For the flight ecosystem, there is no impact on safety margins, so we have not prioritized it.

However, the new liquid feed system requires onboard flight data in order to function properly, so the criticality of this function will increase for that project. We need some security measure to provide an assurance that the received data is not maliciously malformed.

The flight computer has the highest design assurance and security assurance standards of any of SDR's projects, so we can safely consider it a trusted device. If the flight computer asserts that data is good, we can trust it. So, we need some method of determining that the device sending the data is the flight computer.

We can do this via some form of hashing scheme. Consider the following:

1. A private key is generated in SDEC. This can be up to (256 bytes - lora_msg_size).
2. That private key is uploaded to the flight computer and lives in the preset struct.
3. When a telemetry message is generated, we take a buffer with the private key and the message, and then we hash over it using SHA-256.
4. We can then append this hash to the generated message (either half of it (16 bytes) or the whole thing (32 bytes)). This brings our message length up to 64 bytes or 80 bytes, depending on how much of it we use.
5. Continue the transmission process as normal
6. The ground station receives the message, and if the CRC matches, it passes the whole thing including the hash to SDEC.
7. On the other side, SDEC has a copy of the private key. It performs the same hash operation and compares its output to the signature.
   a. If the signature matches, then we have an assurance that both the message content didn't get mutated in transit and that the sender is within the trust boundary.
   b. If the signature matches, then either the message was corrupted in transit or sent outside the trust boundary. Either way, we discard the message and don't propogate the data through to displays.

Notably, since the message is fixed size, we shouldn't suffer from length extension attacks, which is the only known weakness of SHA-2. This does increase message size, which will reduce transmission speed.

Describe alternatives you've considered
See https://github.com/SunDevilRocketry/Flight-Computer-Firmware/issues/191.

Additional context
This is not an urgent feature that has to be worked in the upcoming release. The flight computer cannot be exploited as a result of the base vulnerability.

However, the New Liquids Feed System upgrades the criticality of the ground station and the data flow from it. As such, mitigation FC.NLFS.GS.3 requires the presence of some security measure on LoRa. Priority should increase as we get closer to NLFS completion.

Points of Contact
FC Rev 3 Project Lead / Telemetry & Security SME / NLFS PM & SQA: @ETSells