time-alarm device: Migrate away from comms service

[williampMSFT]

Currently, the time-alarm service leverages the comms system to communicate with the eSPI service (or potentially other relay services. e.g. UART). This is a problem for testing because the comm system requires that all things that talk on it have lifetime 'static, which means that we can't create more than one instance of the time-alarm service, which means that we can't exercise multiple startup paths or multiple hardware mocks.

Per discussion with the rest of the team, there was already some interest in moving from the comms system to direct async calls for other reasons, so we're going to try to fix this in the time-alarm service by migrating to direct async calls. This is going to require changes to the eSPI service to send messages in the new format - see #703