Refactor AlarmCoordinator so that it's not a polling coordinator

[palazzem]

Is your feature request related to a problem? Please describe.

AlarmCoordinator introduced in #74 is a polling integration built on top of a long-polling API. The combination of both means that you poll every 5 seconds, then you are stuck for at most 15 seconds, to then poll again. This introduces unneeded latency as you don't need to wait for the next poll, but you can:

1. Poll
2. If not changed, poll again
3. If changed, update
4. Poll again

Describe the solution you'd like

The long-polling triggers a signal to notify the integration that an update is needed, so we can simply poll and when there is a change, retrieve the data and publish it through async_set_updated_data().

We can still keep AlarmDevice in place, with no need of changing how entities get updated. That could be a further step.

Describe alternatives you've considered

Keep everything as it is, even though it introduces 5 seconds latency if you wait for the next poll to happen.

Additional context

The polling mechanism must be configurable, as it's needed by some customers that don't want to keep the connection always opened with the cloud.

[xtimmy86x]

Check this strange thing:
I decided to update the firmware of the central unit, and, naturally, during the update, it disconnected from eConnect and then reconnected.
Since then, the integration is no longer available.
I tried polling directly with econnect-python from my environment and everything responds.
So, it's something related to Home Assistant logic.

I restarted the integration and everything started working correctly again

This is the log that repeats since it disconnected/reconnected