Support dynamic soc-at-start

[nhoening]

If the SoC at start of scheduling can be known / assumed (e.g. from previous schedules which saved them to a sensor), we should use that.

Right now, we expect it in the flex-model's soc-at-start attribute. Well, the StorageFlexModelSchema actually treats it as optional already. However, before we check configuration against that schema, we make sure we have some starting SoC. First, we try if we got a soc-at-start value explicitly, then check some old-style, deprecated asset attributes, and otherwise simply fall back to 0 if we can't find any of the former.

The function MetaStorageScheduler.ensure_soc_at_start() is where this currently happens, and probably that also a good place to put the enhanced lookup for this issue.

This issue expands our search for a starting SoC, in this order:

• soc-at-start, if given
• otherwise, if a SoC sensor is configured in the flex-model (via the state-of-charge field), use it to get a value.
  • for a sensor, search most recent beliefs
  • if it is a time series, use that directly
  • In the two options above, any found value should not be earlier/later than 4 times the resolution from the beginning of the new schedule. If it is, and thus we found no SoC even though we have a sensor, we should throw an error.
• if none of the above, we treat it like before - look up the deprecated attributes or assume 0.

We should test if this works in both the CLI and API. Maybe in the HEMS script, even?

We should also document the state-of-charge field here, while we're at it.