Release v4.1.0

• (theimo1221) BREAKING: iPersist gains two mandatory members, persistSoilSensor and getSoilMoistureHistory - an own implementation of that interface no longer compiles until it carries them. They arrive together on purpose: a table that is written and never read is a second breaking change waiting to happen, and this way an installation pays for one
• (theimo1221) Add soil moisture as a sensor axis of its own - DeviceCapability.soilSensor, iSoilCollector, iSoilSensor, the SoilSensor shared function, SoilSensorChangeAction and a SoilSensorDeviceData table written every five minutes. Deliberately not a second humidity sensor: a device can measure the moisture of the soil and the humidity of the air at the same time, and those are two quantities that merely share a unit - the COOLO CS-201Z reports 15% soil against 91% air on the same message, and either would have pushed the other out of a shared slot. SmartGardenSensor still writes its soil reading into the ambient humidity slot and is left as it is for now; the axis it would move to now exists
• (theimo1221) Add ZigbeeSoilSensor as the base type every zigbee soil sensor derives from. It carries soil moisture and battery - the states such a sensor always has - and deliberately not ambient temperature or humidity, so a sensor that only reads the soil does not claim to measure the air
• (theimo1221) Add the COOLO CS-201Z (ZigbeeCooloSoilSensor, name your ioBroker device 00-Zigbee-<room>-CooloSoil-<index>). Beyond soil and battery it adds the ambient temperature and humidity axes and counts towards the room aggregates for both, because the sensor sits in a pot in the room air; a sensor in a bed or a lawn would want the soil cluster alone. Its configuration states (soil_calibration, soil_warning, temperature_calibration, the two sampling intervals, temperature_unit) and the dry flag it derives from its own threshold are not mapped and stay reachable through send_payload
• (theimo1221) Record the daily precipitation in iWeatherDaySummary and the WeatherDaySummary table, filled from the day summary the backfill already fetches - no additional request, and existing installations get the column added once rather than the table recreated. The field is optional in both directions: an implementer of the aggregate keeps compiling, and - the part that matters - precipitation is read outside the completeness check that decides whether a day counts at all. Had it joined that check, every answer without the field would have discarded the whole day and the dachs start decision would have lost its history one gradually thinning window at a time. A refetch of the running day that arrives without precipitation keeps the figure an earlier one delivered instead of erasing it, and an absent value is stored as null rather than as a 0 that would claim the day was dry
• (theimo1221) Together these three make a later watering decision possible from recorded data - soil moisture over time against rainfall over time - without that decision existing yet. What is deliberately not done: the weather backfill still runs only where an energy manager drives it, so an installation without one records no weather history