Proposed fix for HELICS_TIME_MAXTIME: redefine to a smaller value

[trevorhardy]

Describe the bug
#2574 and #2534 have shown that, at least for the purposes of the User Guide Examples in Python, there is a consistent problem requesting HELICS_TIME_MAXTIME that tends (but not always) causes the HELICS to fail to grant time to any federate. As a work-around, most if not all of the User Guide Python examples have been re-worked to instead use HELICS_TIME_MAXTIME - 1 and this completely solves the problem. I propose that we re-define the value to something similar.

What is the expected behavior?
It is expected that using HELICS_TIME_MAXTIME doesn't cause the co-simulation to hang.

To Reproduce
See issues #2574 and #2534

Environment (please complete the following information):

• Operating System: macOS 14.7.2
• Language Extension: Python:
• what compiler or setup process did you use: pip install helics

Additional context and information
A brief discussion with @phlptp revealed two details:

1. This may be specific to all of the languages using the C API (e.g. Python, Julia, MATLAB) caused by how the constant is defined in the HELICS library and a potential error in how that gets translated over into the C-API.
2. To resolve the issue with the C API may require more than subtracting 1 ns (one LSB of the constant) but rather may require subtracting one MSB, effectively cutting the maximum temporal range to half of what it is now. We have only seen one use case where a user needed to simulate beyond the existing HELICS_TIME_MAXTIME and this was resolve by treating the granted time as a coarser unit (i.e. 1 day instead of 1 second). That is, it is likely reducing the maximum resolution by half will be acceptable if necessary.