Streamline attribute reporting config and align polling

[SwoopX]

This PR is intended to streamline the behavior in checkLightBindingsForAttributeReporting() and checkSensorBindingsForAttributeReporting() to check if the corresponding bindings exist and require attribute reporting.

For both functions, a grace time of (val.maxInterval * 3 / 2) is now given (the resources must have the maxInterval already set internally), so that basically 2 reports are allowed to have gone MIA before configuring the reporting again. Otherwise, a default value will be assumed (60 * 6 secs for lights, 60 * 15 secs for sensors (previously 60 * 45)).

All this also has been better aligned with the poll manager, which takes the same code as checkLightBindingsForAttributeReporting(). This should ensure light nodes get a proper fall back to polling, in case no reports come in after (val.maxInterval * 3 / 2).

Some XAL related code has been removed as is seemed to be duplicate code, but required a slight amendment of the maxInterval value (now 1200 instead of 3600) to reflect the initial polling conditions.

All in all, this should prevent some unnecessary requests to set up reporting configration and prevent unnecessary polling of light nodes based on a larger maxInterval of the previous allowed 6 minutes (e.g. light nodes maxInterval is configured to 10 mins, but with the old code, it always gets polled after 6 mins. New code would allow for up to 2 missed maxInterval 10 mins reports before falling back to polling).

[ebaauw]

Seems like a good idea, but I don't think I can oversee the impact. The polling and re-issuing the bindings/reporting configuration have always been like magic to me.

[manup]

Merged to check how it behaves in my network, I have 4x IKEA GU10 CW and 2x IKEA E27 dimable lights.