Scope quirk attribute update state to the cluster instance - #1896

Proposed change

While a reported or read attribute is passed through a quirk's _update_attribute, zigpy suppresses the AttributeUpdatedEvent for that attribute (#1754) and remembers the manufacturer code to look it up with (#1760). Both were context variables, and neither was tied to the cluster instance the attribute belongs to. That made them apply in places they were never meant for:

• Tasks and timers started from _update_attribute inherit context variables. If such a task or timer updates the same attribute later, the value only ends up in the attribute cache: no AttributeUpdatedEvent is emitted, so the update isn't persisted and ZHA isn't notified. This is the "Separate issue" described in Fix IKEA battery percentage being doubled twice after firmware read zha-device-handlers#5397: the IKEA battery quirk reads the firmware version in a background task and then corrects the battery percentage, and HA keeps showing the uncorrected value until something else refreshes the entity or the next battery report arrives.
• The suppression was keyed by cluster ID and attribute ID. A quirk that forwards the attribute to the same cluster on another endpoint (or another device) had that update's event suppressed as well, and nothing emitted it afterwards.
• The manufacturer code was matched on the attribute ID alone. A quirk that forwards a manufacturer-specific report to an attribute with the same ID on another cluster had that attribute looked up with the manufacturer code. For a standard attribute the lookup fails, so the value was stored as an unknown "legacy" attribute and the event had no attribute name.

This PR replaces both context variables with a single dict on the cluster instance, mapping the attribute IDs currently being passed through the quirk to their manufacturer codes. It's only filled for the duration of the synchronous _update_attribute call, so it can't apply to anything running later, and it only applies to the cluster instance that received the attribute. _update_attribute calls for that attribute ID on that cluster behave as before.

Additional information

• This should not be released before Fix IKEA battery percentage being doubled twice after firmware read zha-device-handlers#5397. Without that fix, the IKEA quirk's background task writes the battery percentage doubled twice (a report of 50 becomes 200). Today that wrong value stays hidden in the cache because its event is suppressed. With this PR it is emitted, so old-firmware IKEA devices would show twice the real percentage (more than 100% above half charge) until the next report. With both changes, the task emits the correct value (verified with a battery report sent through the quirk at the head of that PR: AttributeReportedEvent 50, then AttributeUpdatedEvent 100).
• Behavior change for quirks: an update of the same attribute from a task or timer started in _update_attribute is now treated like any other update the quirk does on its own. It emits an AttributeUpdatedEvent, and the attribute is looked up without the manufacturer code. If the cluster defines several attributes with that ID, a deferred update by integer ID is therefore ambiguous and is stored as a legacy value, where it previously updated the manufacturer-specific attribute by accident. I found no quirk in zha-device-handlers that does this.
• Tests: test_quirk_deferred_attribute_update_emits_event (task and timer, report and read), test_quirk_forwards_attribute_update_to_other_endpoint (report and read) and test_quirk_manufacturer_code_context_other_cluster (known and unknown attribute) cover the three cases above and fail on dev without the fix. test_quirk_attribute_update_nested_and_failing covers nesting and cleanup after an exception.
• The zha and zha-device-handlers test suites pass against this branch.