Correctly handle "hours to show" for footer graph

[spacegaier]

Breaking change

Proposed change

This PR fixes two issues:

1. The old coding did always check against 24 hours to see whether previously loaded history entries should be discarded rather than using the config parameter "hours to show".
2. The old coding did not account for the "initial state" of the history. So if 12 hours should be shown, but only 13 hours ago and then 2 hours ago did state changes occur, the frontend receives also the history entry from 13 hours ago from the backend. So the initial graph rendering was always fine. However, during the subsequent updates (when only the delta of newly recorded history entries is retrieved from the backend), the frontend did discard all cached history entries that lie outside the 12 hours. That would mean that "initial state" history entry would be lost (and effectively only values from 2 hours ago until now would be rendered).
   This PR now ensures that the last previous history entry that now lies outside the "hours to show" is retained so that the graph has a correct "entry value" = value on the left border of the graph.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes Line graph card loose 24h older data on auto-update when showing 48h #8055
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[spacegaier]

@zsarnett Since you did the implementation for the cached history, could you have a look at my changes if those look good to you

[spacegaier]

@bramkragten I verified your proposals. They indeed work as the order of entries in this._stateHistory plays no role (the coordinates() logic seems to take care of the sorting on its own already), so my convoluted attempt to retain the order was not needed.

[spacegaier]

@zsarnett Ping. It would really like to have that in the next beta 😄. The issue drives me nuts on my dashboard.