[CIP Sync] Timesync Parameters attribute: Invalid values are accepted, lead to silent failure

The sync parameter 'interval' of the two sync signals 0 and 1 must be a multiple/fraction of each other, which is a requirement by the HAL/Switch to accept them.
This condition is not properly checked in the CIP Time Sync object (attribute 768). Instead, the configuration silently fails, or has otherwise undesired/undefined results.

User Story:

If the host application attempts to configure invalid time synchronization parameter values, it wants to receive immediate feedback in the form of an error code in the confirmation packet.

Work to do:

• The parameter checks for ulSync0Interval and ulSync1Interval (TIMESYNC_SYNC_PARAMETERS_T) have to be improved and made consistent to make any inconsistency explicit at the CIP level.
  Seems like there is no function CipTimeSync_Validate_768() available.
  Consider adding it in order to implement the parameter checks.
• Adaption shall be made for trunk and current hotfix branch.
  Below comment from Marc suggests to adapt the PTP component instead of adapting the EipCore? --> Clarify and decide what to do.
• The protocol API manual shall be extended by a definition of the valid ranges/values with regards to that limitation.
• Add/extend a test case that ensures that the stack rejects invalid combinations of intervals.
• Add a migration note entry that describes the changed parameter checks.
  This is necessary, as host applications might have used invalid interval combinations, but did not run into an error during stack configuration.
  In such a scenario CIP Sync worked without issues even though the application did not use the sync 1 signal.
  With the proposed change, such applications might have to be adapted.

Points related to other projects:

• Check demo applications V3 and V5 for used time sync parameter values and correct values if necessary.
• Maybe add validate function to PTP component.