Store remanent data in return path of object change indication instead of forward path

Currently, when an attribute is set in consequence of, e.g., a successful Set_Attribute_Single request from the bus, a change indication is generated towards the host.

In the send path of that change indication remanent storage of the new attribute value is requested in the background worker thread. Thus, it is not determined when exactly the remanent is actually written.

There may be certain situations where this may lead to problems, e.g. if full power cycle reset is performed via the Identity object's reset service before the data could be written by the background worker (which may also be busy with other stuff in the meantime). This would result in remanent data not being stored despite of a successful Set_Attribute_Single service which has been replied to, for which the host was indicated and has responded.

Solution: If we stick with asynchronous storage of remanent data, then we must synchronize the event "remanent storing completed" with at least the event "power cycle will now be performed" and maybe other ones, too. Clarify.