Don't log ParametersRequest & AlarmLimitsRequest initialization in firmware

[ethanjli]

This PR fixes #341 by:

• Making the Parameters and AlarmLimits request/response services only generate log events for parameters and alarm limits changes (besides ventilation start/stop) after the first ParametersRequest and AlarmLimitsRequest messages have been received from the backend, respectively. This means that unplugging the MCU and plugging it back in while the firmware is running will generate log events on loss and reestablishment of the MCU-backend connection (provided by #344) and on stoppage and starting of ventilation, but it won't clutter the event log with redundant parameter & alarm limits change events.
• Making the StateSegment store in the firmware track whether it has received an initial ParametersRequest and an initial AlarmLimitsRequest.
• Renaming the Pufferfish::Application::States class to the Pufferfish::Application::Store class, to be consistent with naming in the backend and frontend.

Note: this PR does not provide the same behavior in the backend simulator. This should happen in a future PR, after/when functionality is added to save/load the event log from the filesystem. Only after that's done would we be able to test it.

This PR should be merged after #344 is merged into develop.

[rohanpurohit]

Everything looks good. tried to generate erroneous/extra log events multiple times on disconnecting/reconnecting MCU and it works as expected.

[ethanjli]

Great! Then I'll merge in this PR as prototype-grade code. 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

For future PRs, let's start having you use Github's Code Review approvals feature, where if it looks good to you according to the review criteria (which could just be testing the functionality, or could also include code review if you want), then you'll do the formal Github approval. Thanks!