Add SetStepDuration and TimeAdvanceModes

[KonradBreitsprecherBkd]

This PR adds support for dynamic time step management in the SIL Kit orchestration layer by introducing SetStepDuration and TimeAdvanceMode features. The changes enable participants to either advance time based on their own step duration or synchronize with the time points among all participants.

Key Changes:

• Introduced a new TimeAdvanceMode enum with two modes: ByOwnDuration and ByMinimalDuration
• Renamed the internal SetPeriod method to SetStepDuration and exposed it in the public API
• Added a new overload of CreateTimeSyncService that accepts a TimeAdvanceMode parameter

With these changes, a participant can reduce the step duration in a critical phase where a more fine grained synchronization is needed.

[VDanielEdwards]

Are you sure using the minimum of the other sim. step durations works correctly if not all sim. step sizes are multiples of the smalles sim. step size? Especially if the 'minimal-duration' participant performs a hop-on and lands on an 'odd' current time.

Example with two participants A and B, the numbers are the 'now' timestamps, ordered as they would occur in SIL Kit (same x position means these steps don't wait for each other):

A: 0 2   4 6 8   10 12 14    16 18
B: 0   3   6   9    12    15    18

A participant C that uses the mimimum-duration mode added to the next run of that simulation, would do the same as participant A. Is this the desired behavior?

A: 0 2   4 6 8   10 12 14    16 18
B: 0   3   6   9    12    15    18
C: 0 2   4 6 8   10 12 14    16 18

To the best of my knowledge, if the participant C uses hop-on and joins a running simulation the following could happen (if C joins such that it's first now is taken from B):

A: 0 2   4 6 8   10    12    14    16    18
B: 0   3   6   9       12       15       18
C:             9    11    13    15    17

My initial feeling is that the selected duration should be computed as the difference between the 'current time' (of the minimal-duration participant) and the earliest 'next time' across all other 'normal' participants?

This would lead to the following in the starting-together case:

A: 0 2   4 6 8   10 12 14    16 18
B: 0   3   6   9    12    15    18
C: 0 2 3 4 6 8 9 10 12 14 15 16 18

And the hop-on case:

A: 0 2   4 6 8   10 12 14    16 18
B: 0   3   6   9    12    15    18
C:             9 10 12 14 15 16 18

Notice that they behave the exact same way in this case.

[KonradBreitsprecherBkd]

Thanks @VDanielEdwards, you're right. Only adding the min. duration can lead to unaligned 'grids'. I will change the calculation such that all participants configured with ByMinimalDuration are guaranteed to trigger the SimStep with the same time.