Add heatAndCoolDemand support to LyricDevice

[clutch2sft]

Resideo's device response includes a heatAndCoolDemand object (equipment stage, demand percentage, active stages, fan/circulation fan request) that aiolyric never parsed at all. Adds a HeatAndCoolDemand class and LyricDevice.heat_and_cool_demand property, following the same pattern as the existing OperationStatus handling.

Note the API uses PascalCase keys here (CurrentStage, Demand, Mode, StagesOn, FanRequest, CirculationFanRequest), unlike the camelCase used elsewhere in the same response - that's what Resideo actually returns, not a typo.

[timmo001]

Can you add a redacted example of this part of the live /v2/devices/thermostats/{deviceId} response? heatAndCoolDemand is not included in the public response docs, so I cannot verify the field location or casing: https://developer.honeywellhome.com/lyric/apis/get/devices/thermostats/%7BdeviceId%7D-0

[clutch2sft]

Can you add a redacted example of this part of the live /v2/devices/thermostats/{deviceId} response? heatAndCoolDemand is not included in the public response docs, so I cannot verify the field location or casing: https://developer.honeywellhome.com/lyric/apis/get/devices/thermostats/%7BdeviceId%7D-0

Here's a redacted excerpt from a live /v2/devices/thermostats/{deviceId} response (T9-T10 thermostat), captured via Home Assistant's aiolyric debug logging, showing heatAndCoolDemand in place alongside the already-supported fields:

{
  "displayedOutdoorHumidity": null,
  "heatAndCoolDemand": {
    "CurrentStage": 0,
    "Demand": 0,
    "Mode": "Heat",
    "StagesOn": [false, false, false, false],
    "FanRequest": false,
    "CirculationFanRequest": false
  },
  "vacationHold": {"Enabled": false},
  "currentSchedulePeriod": {"Day": "Monday", "Period": "Wake"},
  "scheduleType": {"scheduleType": "Timed", "scheduleSubtype": "NA"},
  "operationStatus": {"mode": "EquipmentOff", "fanRequest": false, "circulationFanRequest": false},
  "deviceModel": "T9-T10"
}

Confirms heatAndCoolDemand is a sibling of operationStatus/vacationHold/etc. at the device level, and that all six of its keys are PascalCase (CurrentStage, Demand, Mode, StagesOn, FanRequest, CirculationFanRequest) — consistent with what this PR implements.

Also noticed something extra: this same capture shows currentSchedulePeriod: {'Day': 'Monday', 'Period': 'Wake'} in PascalCase, but the current code still reads lowercase day/period — a real, currently-unreported bug.