Add opt-in device-backed sensor controls

[PrzemyslawKlys]

Successor to #6052, rebuilt directly on the v3 architecture merged by #6562.

Summary

• add an explicit opt-in switch on the integration service device; the existing bulk options editor remains available unchanged
• expose each configured waste sensor as a child device with focused configuration entities and safe create/delete actions
• preserve existing sensor unique IDs and history when controls are enabled or a sensor is edited in the legacy flow
• store stable v3 WasteType.id filters for new sensors while resolving legacy names and aliases at read time without eager migration
• make creation actions idempotent and add actions for waste types discovered by later fetches
• cancel coordinator time trackers and delayed callbacks on unload

No generated documentation or translation output is included.

Branch status

Rebased on the current release/3.0.0 branch, including the merged CI-floor updates from #6988 and #7017. This remains a draft with no new feature scope and can be retargeted to master after the 3.0 tag, as requested.

Validation

• 46 focused configuration, sensor-attribute, lifecycle, and config-flow tests passed
• 3,112 passed, 4 skipped, and 2,139 deselected in the complete offline suite
• all 619 offline provider fixtures previously passed in isolated batches
• Ruff, Ruff format, codespell, Bandit, mypy, and pyright passed against the release branch dependency set
• independent compatibility review findings were addressed and revalidated

[markvp]

Thanks for this, it's substantial and clearly careful work, especially around preserving unique IDs and history. It's already milestoned 3.1.0, which is right: it's an additive, opt-in feature rather than something the 3.0 migration requires, so I don't want it merging into the 3.0.0 major and widening that release's scope.

The main thing to sort is the branch. It's currently based on release/3.0.0. Please keep it rebased there for now; once 3.0.0 is tagged we'll retarget it to master, which is where 3.1 will land, so the major stays limited to the migration and its regressions. It also depends on #6988 (the v3 CI floor) for a green validation run, so that one should land first. Nothing else needed from you right now. Thanks again.

[PrzemyslawKlys]

Rebased onto the current release/3.0.0 without adding feature scope; the only merge conflict was the shared pytest.ini test list. This remains a draft for retargeting to master after the 3.0 tag as requested. Validation is green locally: 46 focused tests and 3,112 passed / 4 skipped in the complete offline suite, with the applicable lint and type checks passing.