Add optional 64-bit system clock APIs

[fdesbiens]

ThreadX exposes its application-controlled system tick counter through tx_time_get() and tx_time_set(). The documented 32-bit counter wraps after approximately 497 days at 100 ticks per second and 49.7 days at 1,000 ticks per second. Applications that need a long-running, high-resolution tick value currently have to maintain their own extension.

I want an optional 64-bit system clock facility with these requirements:

• The existing tx_time_get() and tx_time_set() signatures, behavior, and ABI remain unchanged.
• The feature is enabled by a compile-time option and is disabled by default.
• New public get and set services expose a 64-bit tick value using a portable ThreadX type.
• The 32-bit and 64-bit services represent the same logical counter. The existing getter returns its low 32 bits, the existing setter zero-extends its argument, and the new setter updates the complete value.
• Reads, writes, and rollover handling are atomic from every context allowed by the corresponding existing services, including SMP configurations.
• Enabling the feature does not change application-timer or thread-timeout behavior. Those facilities continue to use their existing relative-tick implementation.
• Disabled builds incur no additional timer-interrupt runtime cost or storage.
• The implementation either supports every maintained port or rejects unsupported configurations at compile time. It must not expose a counter that is updated only by selected ports.
• ThreadX Modules receive compatible access to the new services without changing the existing module ABI.
• Event tracing and event logging handle the new services consistently with the existing time services.
• Regression tests cover initialization, get/set behavior, rollover across 0xFFFFFFFF, interaction with the legacy services, and relevant SMP synchronization.
• The ThreadX user guide documents the option, APIs, rollover semantics, supported configurations, and distinction between application ticks and calendar time.

I consider changing the existing services to accept or return a 64-bit value out of scope because that would break established source, binary, and module interfaces.

I want to be clear that no maintainer or contributor is currently assigned to implement this feature. This request records the desired behavior, but it carries no delivery commitment or schedule.