API Change: Object change indication handling should be implicit, without host actively taking over new attribute values, but passive takeover

Currently, when an internal object's attribute changes its value due to bus access, an object change indication is generated towards the host expecting it to execute the following sequence of operations:

1. Validate attribute value
2. Reply to the object change indication which effectively causes the stack to reply on the bus. (The ulSta field in the reply's header determines whether or not an error is sent on the bus)
3. Eventually, actively apply new attribute value by re-issuing the change with a EIP_OBJECT_CIP_SERVICE_REQ

We want to change the behavior such that the host omits step 3. Instead, the changed attribute value would implicitly be applied when the object change indication is replied to (step 3), before the reply is sent on the bus.