API change: Forbid access to all CIPHIL services from the host application.

Proposal for an API change: Forbid access to all CIPHIL services from the host application.
Where access to such functionality is required, add dedicated DPM services.

It is odd that the host application can access these services. They are badly documented and tested. Some of them are not to be called by the host application at all because it would have malicious effects. Anyway, there is no technical measure to prevent the host application from calling these services. That is bad design.

As far as I can see, for EIP adapters, the only services of interest are CIPHIL_CMD_SET_ATTR_OPTION and CIPHIL_CMD_GET_ATTR_OPTION.
These should be mapped to explicit DPM services, which are to be defined. Maybe sth. like:

EIP_OBJECT_ENABLE_DISABLE_ATTRIBUTE
EIP_OBJECT_GET_SET_ATTRIBUTE_PERMISSION
EIP_OBJECT_ENABLE_DISABLE_ATTRIBUTE_CHANGE_NOTIFICATION

Furthermore, there are CIPHIL_CMD_TCP_ADD_IANA_PORT_ADMIN_ENTRY and CIPHIL_CMD_TCP_REMOVE_IANA_PORT_ADMIN_ENTRY which should be callable by the host application.

The basic idea is to restrict the API, i.e.

1. change notifications cannot be disabled for remanently stored attributes
2. admin access cannot be revoked for attributes
3. very specific internal services (reset object, etc.) cannot be called by the host application.
4. remove redundancies between specific DPM services and stack services.
5. technically disallow access to untested and poorly documented stack-internal services.

Consequently, EIP_OBJECT_CIP_SERVICE_REQ will only be capable to call service IDs in the range [0...255], just like external clients.
This would greatly reduce the complexity in especially the documentation, cleanup the API and remove all the untested dirty spots.
In fact, the initial design decision to do this (expose stack specific API to the host application) was bad.

For scanners, this has to be considered separately, since we may call more hilscher-specific services from the host application.

Further stuff to be optimized during this rework:

1. Remove CIP_FLG_UPD_STRAT_AFTERRESET: it is only for informational purpose. It can be documented in the API manual instead for each attribute if it takes effect on the fly or a reset is needed to apply changed values.
2. The attribute permission flags included lower permission access (i.e. BUS_GET implies HOST_SET). There seem to be no exceptions to that in the future. Hence, each permission is implemented as a distinct bit. Instead, this can be reworked to a value-semantic for set access and get access. (0 - NO ACCESS, 1 - ADMIN ACCESS, 2 - HOST ACCESS, 3 - NO ACCESS). Saves two bits for future use.
3. A issue we currently have is that non-implemented attributes are aslo covered by the DISABLED flag as well as attributes which are disable din the first place and can be disabled later by the host. This is odd. User can enable attributes which are not meant to be enabled. e.g. class attributes 4, 5, etc. (see for instance PRODEISV5-167)