Rework NotifyMessageRouter to cope better with services

The current implementation of NotifyMessageRouter takes a certain structure of EPath as given in order to give a correct result or error code.

As seen in the issues #125 #138 #139 #140 #143 this assumption is invalid for Get/Set/Insert/Remove Member services, and perhaps other services too. A better way would be to first check if the service is supported by the CIP object and which service is requested, and then parse and create the correct structure for the service to be handled