timing: ARM Cortex-M timing functions return incorrect number of cycles on cycle counter wrap around

[stomschik-ask]

Describe the bug
The cycle counter wrap around on ARM Cortex-M is handled incorrectly causing timing_cycles_get() to return an extremely high number of cycles if the cycle counter wraps around between start and end. The issue is caused by storing the timestamps in a timing_t variable defined as 64-bit integer, but the cycle counter of the ARM Cortex-M only uses 32-bits of the 64-bits. Subtracting the two 64-bit integers without casting them first to 32-bit will result in an incorrect result. The following patch seems to fix the issue:
arch_arm_core_cortex_m_timing.patch

To Reproduce

1. Call timing_init() to initialize the timer.

2. Call timing_start() to signal the start of gathering of timing information.

3. Call timing_counter_get() to mark the start of code execution.

4. Call timing_counter_get() to mark the end of code execution.

5. Repeat step 3 and 4 until timing_counter_get() returns a lower value for end of code execution than for start of code execution, i.e. a wrap around of the timer has occurred between these two steps.

6. Call timing_cycles_get() to get the number of timer cycles between start and end of code execution.

Expected behavior
The wrap around of the cycle counter shall be handled correctly, i.e., the number of cycles between start and end should be returned by timing_cycles_get()

Environment (please complete the following information):

• OS: Windows
• Zephyr SDK 0.16.8
• Zephyr 3.7.0