Add deprecation database to prevent use of deprecated API paths

[lackas]

Summary

This adds a deprecation database and tooling to prevent accidentally adding code that uses deprecated Viessmann API paths — saving review effort by catching these issues before a PR is submitted.

Background

During review of #689, @CFenner pointed out that some features might be deprecated. Looking into it, I found that I had accidentally added a getter for heating.cop.green, which is deprecated (replaced by heating.cop.photovoltaic, removal 2025-12-31). The existing test_deprecatedProperties test didn't warn me because the test response data for that device doesn't include the deprecated marker — it was only visible in a fresh API dump. I wanted to improve this so deprecated features are caught automatically before submitting a PR.

What this adds

tests/deprecated_features.json — A persistent database of 106 known deprecated features, merged from all test response files and fresh device dumps. Each entry records:

• removalDate and replacement info from the API
• firstSeenIn / firstSeenOn — provenance tracking (which file first reported it, when)
• sources — all files that confirm the deprecation

check_deprecations.py — A developer tool that:

• Reports deprecated features used in code (grouped, with removal dates and replacements)
• Keeps the database up to date from test data (--update)
• Ingests fresh device dumps (--update dump.json) and highlights newly discovered deprecations
• Collapses repeated entries (e.g. rooms.*.sensors.window.openState (24x))

Enhanced test_deprecatedProperties — Now also checks the database, so deprecations known from any source (not just what's marked in test data) are caught in CI.

How fresh dumps help

A feature deprecated in one API response is deprecated everywhere — but not all test data files include the deprecated marker (older dumps, or devices that don't expose it). Fresh dumps, even for devices that already have test data, can reveal deprecations missing from existing data. You don't need to commit the full dump — just run:

python3 check_deprecations.py --update path/to/dump.json

This extracts only the deprecation info into the database. I checked all dumps attached to open PRs (#645, #667, #695, #696) and they don't contain new deprecation info beyond what's already in the database.

Example output

=== WARNING: Deprecated features used in code ===

  ventilation.operating.programs.comfort
    Removal: 2024-09-15 (PAST DUE)
    Used in code: PyViCareVentilationDevice.py
  ...

=== Past removal date (not used in code): 101 features ===

  heating.cop.green
    Removal: 2025-12-31 (PAST DUE)
    Replaced by: replaced by heating.cop.photovoltaic
    From dump: device_0_features.json

  rooms.*.configuration.window.openState (24x)
    Removal: 2024-09-15 (PAST DUE)
    From dump: device_RoomControl-1_features.json
  ...

=== Summary ===
106 deprecated features in database
5 used in code (ACTION NEEDED)
101 past removal date
0 upcoming

[CFenner]

Is data that is added on a PR validated (--update) automatically? Maybe we can have something similar to this: https://github.com/openviess/PyViCare/blob/master/.github/workflows/format.yml

[lackas]

Not yet, but good idea — I'll add a CI workflow similar to format.yml that runs check_deprecations.py --update and verifies no diff, so new test data automatically keeps the database in sync.

[lackas]

The CI job is failing because check_deprecations.py correctly detects 5 deprecated features still used in the ventilation code (all past due since 2024-09-15, see #708). Since fixing those requires an interface redesign and someone with ventilation hardware to test, how would you like to proceed? We could use continue-on-error: true on the check for now so it's visible but non-blocking until the ventilation migration is done.