Summary

Adds full support for the Stiebel-Eltron WPL33 heat pump variant as a
new device family, following the same conventions as the existing WPL13/17/23 profiles.
Along the way this also fixes a couple of small pre-existing issues and adds a generally
useful, opt-in addition to the shared wp_core component.

What's new

• yaml/wpl33.yaml: new device profile, gated by the -DWPL_33 build flag (mirrors
  wpl13.yaml/wpl17.yaml/wpl23.yaml).
• Independent from wpl_base.yaml (unlike WPL13/17/23): a large fraction of the properties
  wpl_base.yaml assumes exist turned out to never return real data on this unit, confirmed via
  live CAN bus logs from a real device. Rather than fight !extend/!remove around baked
  on_boot lambda code (doesn't clean up after itself), wpl33.yaml opts in explicitly to
  everything it actually needs, one property at a time — easy to trim further as more turn out
  to be unsupported.
• CAN bus specifics for this unit: 20kbps bit rate (vs. the family default 50kbps), Heizmodul
  on CAN id 0x500 (vs. default 0x514), datetime synced via the Manager CAN node instead of
  Kessel.
• WPL33-specific Betriebsart (operating mode) strings in mapper.cpp — this unit's mode
  names differ from WPL13/17/23.

New shared templates (usable by any future device family)

• templates/wp_text.yaml: string-valued CAN properties (Type::et_err_nr, et_dev_id,
  etc.) as text_sensor, actively polled — parallel to wp_temperature.yaml/wp_generic.yaml
  for numeric properties.
• templates/wp_binary_property.yaml: bool-typed CAN properties as proper binary_sensor
  entities, instead of forcing them through a numeric sensor (which crashes with
  bad_variant_access on a bool-holding value).
• templates/wp_generic_passive.yaml / templates/wp_text_passive.yaml: for properties
  the unit broadcasts unsolicited (never in response to a request) — identical to
  wp_generic.yaml/wp_text.yaml but without any queueRequest calls, so they're never
  actively polled, only passively received.
• templates/wp_datetime.yaml: parameterized with a target CAN node (wpl_base.yaml
  passes it through via a new datetime_target substitution), since WPL33 needs Manager
  instead of the family default Kessel.

Diagnostics: opt-in unmapped-property tracker

components/wp_core/unmapped_tracker.h — logs and persists (via flash) any CAN property id
that arrives on the bus but has no property.h entry, exposed as a text_sensor. Purely a
discovery aid for extending property.h on new/unfamiliar units; off by default
(core.yaml's track_unmapped_properties substitution) since it writes to flash on every
newly-seen id. Prunes entries on load once their property id gets a real mapping, so the list
doesn't accumulate stale/fixed ids forever.

Fixes picked up along the way (affect all device families)

• Migrated the deprecated esphome.platformio_options.build_flags/build_unflags to the new
  flat esphome.build_flags across every device config (support for the old key is being
  removed in ESPHome 2026.12.0). build_unflags was dropped outright rather than migrated —
  it's silently ignored under the native ESP-IDF toolchain, so it was already dead.
• esp32-poe-technik.yaml: added a commented-out wpl33 package line for discoverability,
  matching how wpl13/wpl17/wpl23 are already listed (not enabled — this example config
  runs THZ504).

Testing

• Built, flashed, and run on a real WPL33 unit (20+ properties confirmed against live CAN
  telemetry; several properties present in the original draft were confirmed dead on this
  hardware and removed to reduce bus load; a few genuinely missing ones were added back with
  corrected CAN node targets).
• esphome config validated for every touched device family (wpl13/17/23, thz304/404/504/
  5_5_eco, ttf07) to confirm the shared-file changes (wpl_base.yaml, core.yaml, template
  renames) don't regress anything outside WPL33.