Issue #3586550: Add automatic cleanup / retention for monitoring_sensor_result records

Closes #3586550.

Adds an optional retention policy for the monitoring_sensor_result entity so the table no longer grows unbounded when sensor_call_logging is set to all (or to on_request on a site that changes status a lot).

Changes

• Setting: monitoring.settings:result_retention_days (integer, default 0 = keep forever). Exposed on the monitoring settings form as a number field alongside the existing logging toggles.
• Cron prune: monitoring_cron() deletes any monitoring_sensor_result with timestamp < request_time - retention_days * 86400. Done via the entity storage (not raw SQL), in 500-entity chunks, only when retention_days > 0.
• Index: new storage-schema handler SensorResultEntityStorageSchema adds an index on timestamp, so the prune (and the existing "recent results" queries) don't scan the full table.
• Upgrade path: monitoring_update_8104() seeds the default value and applies the timestamp index to existing installs via EntityDefinitionUpdateManager::updateEntityType().
• Test: MonitoringRetentionTest covers both 0 = keep all and retention > 0 paths. The boundary case (row exactly at now - N days) is kept because the cutoff condition is strict <.

Backwards compatibility

No behavioural change when left at the default 0. Existing sites continue to accumulate logs as before until an admin opts in.

Manual test

1. Enable monitoring, set Monitoring event logging to Log all events, enable Run sensors during cron.
2. Let cron run until SELECT COUNT(*) FROM monitoring_sensor_result has a few hundred rows.
3. On the settings form, set Result retention (days) to 1 and save.
4. Backdate a row: UPDATE monitoring_sensor_result SET timestamp = UNIX_TIMESTAMP() - 2*86400 WHERE record_id = 1.
5. Run cron (drush cron). Row 1 is gone, recent rows are kept.