Implement alarms in backend simulator

[ethanjli]

This PR:

• Decomposes the backend simulator module into several classes, which will also be the rough structure for the firmware alarms implementation.
• Adds reusable alarms functionality for parameters based on alarm limits requests.
• Simplifies the alarms-related message fields of the communication protocol by unifying min and max record types into a Range message type.
• Renames the backend simulator module from ventserver.simulation to ventserver.simulator, as simulation is now a subpackage

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

[ethanjli]

@Sudhir-dev Can you review the changes I made on the frontend to see if anything looks wrong, as well as try to test out the new alarms-related functionality by running the frontend and the backend simulator (which is now ventserver.simulator instead of ventserver.simulation) together, to identify any behavior which looks questionable?

[ethanjli]

@renjipanicker Just a heads-up, in this PR I've fixed the decomposition of functionalities between firmware/ventilator-controller-stm32/Core/Inc/Pufferfish/Protocols/States.tpp and firmware/ventilator-controller-stm32/Core/Inc/Pufferfish/Application/States.tpp. Previously, the Protocols/States.tpp file contained some application-specific logic in the StateSynchronizer::input method for checking which message types to allow; that was something I had forgotten to update previously, so here I have moved that into a new States::should_input static method in Applications/States.tpp.

[Sudhir-dev]

@Sudhir-dev Can you review the changes I made on the frontend to see if anything looks wrong, as well as try to test out the new alarms-related functionality by running the frontend and the backend simulator (which is now ventserver.simulator instead of ventserver.simulation) together, to identify any behavior which looks questionable?

I have verified. Alarm is triggered based on alarm limit configured