Unify attribute's semantic kinds "OnTheFly" and "None"

Currently, object attributes may be of one of the follwing three semantic kinds:

• "none": New/Set attribute values are taken over immediately and applied when acknowledged by the host application.
• "ChangeOnReset": The attribute value can be written exactly once after a device reset has been performed. This type is not of further interest at this point.
• "OnTheFly": New attribute value is taken over and applied right away by the stack. There are no further actions neccessary from the application side, except storing non volatile data.

Here, "acknowledgement by the host" is illustrated by the following example:

1. A Set_Attribute_Single service arrives from the bus
2. The registered host application receives an object change indication addressing the attribute and containing the new attribute's value. Depending on the attribute semantic type, the new value may already have been "applied" (on-the-fly), or not (none). In any case, they were "taken over".
3. The host replies to the change indication which causes the response to be send on the bus with a success status (independently of the return code passed back with the response to the change indication).
4. The host itself invokes a Set_Attribute_Single service with the attribute address (class, instance, id) and the new data it received with the change indication, which causes the stack to "apply" the new attribute value for attributes of the semantic type "none" and which has no further meaningful effect for attributes of the semantic type "OnTheFly". This is the actual "acknowledgement".

In order to simplify the control flow of the stack and to improve insight at the host application API level, the "OnTheFly" attribute semantic should be removed entirely. Instead, the operations "new attribute value is taken over" and "new attribute value is applied" should be unified into a single operation.

Consequently, attribute values should no longer be taken over instantly, but when the host acknowledges. This leads to the following new control flow:

1. A Set_Attribute_Single service arrives from the bus
2. The registered host application receives an object change indication addressing the attribute and containing the new attribute's value. The new value has not been taken over nor applied yet, it was just passed to the host in the object change indication.
3. The host replies to the change indication with either a success or error status. This causes the response to be send on the bus with accordingly a success or failure status code.
4. The host itself invokes a Set_Attribute_Single service with the attribute address (class, instance, id) and the new data it received with the change indication, which causes the stack to "take over" and "apply". This is the actual "acknowledgement". If the host decides to reject the attribute change it would not invoke a Set_Attribute_Single service.

Along with this change, we need to pay attention to the implementation of the Set_Attribute_List service, and we need to carefully consider the point in the control flow where remanent data is stored by the stack or the host itself.