Hue specific updates with attribute reporting

[duvholt]

The reason I started looking into this is because I found a bug with timed effects:

The following request should result in a sunrise effect which peaks at 10% brightness

{
  "dimming": {
    "brightness": 10
  },
  "timed_effects": {
    "effect": "sunrise",
    "duration": 10000
  }
}

But since we send both standard Zigbee updates and Hue updates (when necessary) this results in the following:

> [server1] Sending {"topic":"kontor/desk/set","payload":{"brightness":25.400000000000002,"transition":0.4}}
> Sending hue-specific frame: b000010009f2
> [server1] Sending {"topic":"kontor/desk/set","payload":{"command":{"cluster":64515,"command":0,"payload":{"data":[176,0,1,0,9,242]}}}}

❯ echo 'b000010009f2' | cargo run --example hz-parse
| flag | on | br | mrek | (colx,coly) | effect ty. | es | gradient data                                           | grad | fade |
==================== b000010009f2
| 00b0 :    :    :      :             : Sunrise    : f2 :                                                         :      : 0001 |    FADE_SPEED | EFFECT_TYPE | EFFECT_SPEED

Notice the lack of brightness in the effect.

In theory I think this could lead to a race condition where the light goes to 25% brightness after 0.4s, but it seems like the effect is always ran last.
A quick fix for this would be to add brightness to the Hue specific update under some conditions, but I wanted to see if we could get rid of the workaround (and potentially other bugs like this) by using attribute reporting.

After this PR the previous request results in this:

> Sending hue-specific frame: b2001a010009f2
> [server1] Sending {"topic":"kontor/desk/set","payload":{"command":{"cluster":64515,"command":0,"payload":{"data":[178,0,26,1,0,9,242]}}}}
> [server1] Sending {"topic":"kontor/desk/get","payload":{"brightness":"","color":"","state":""}}

| flag | on | br | mrek | (colx,coly) | effect ty. | es | gradient data                                           | grad | fade |
==================== b2001a010009f2
| 00b2 :    : 1a :      :             : Sunrise    : f2 :                                                         :      : 0001 |    BRIGHTNESS | FADE_SPEED | EFFECT_TYPE | EFFECT_SPEED

From my testing this seems to work consistently, but it does lead to double the amount of Zigbee messages when doing light updates. I don't personally notice any issues, but I guess a huge Zigbee network could have problems handling all the read requests. I think this could be handled by doing debouncing or something similar to throttle the flood of read attributes when for example selecting color.