syscalls: implement getThreadCpuTime syscall

[R4ken]

Implement syscall based on declared getCpuTime function

JIRA: RTOS-1088

Description

Add syscall allowing us to get information on how much time did actual thread spend on CPU.

Motivation and Context

See: phoenix-rtos/libphoenix#431
Added due to performance reasons, existing syscalls (threadsinfo) give info on first n threads on threads tree which would make us search for our thread on the list

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (ia32-generic-qemu, armv7a9-zynq7000-qemu)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work
  • time/clock_gettime: add handling of CLOCK_THREAD_CPUTIME_ID flag libphoenix#431
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

9 462 tests  ±0   8 873 ✅ ±0   50m 36s ⏱️ +39s
  561 suites ±0     589 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 9508f1e. ± Comparison against base commit 76e72e4.

♻️ This comment has been updated with latest results.

[oI0ck]

cpuTime is updated only on rescheduling, thus it does not well represent the time spent executing on the CPU

[oI0ck]

Okay, I was wrong on the previous comment. Rescheduling happens on a timer IRQ, hence the cpuTime should be kept up-to-date correctly. LGTM

[agkaminski]

I don't like expansion of syscalls list if it's not strictly necessary - this information might be e.g. a part of threadsinfo syscall instead.

[oI0ck]

Right, haven't noticed that. threadsinfo actually outputs this parameter too, so adding this syscall should be redundant

[adamgreloch]

Note that the PR description acknowledges that the threadsinfo already does output cpuTime, but it does so for the first N threads and is generally heavy performance/memory wise, hence this change.
So while I also don't opt for adding a seperate, and such a limited, syscall, IMHO there's a good reason to generalize the threadsinfo in a way that allows per-thread queries and maybe even per-parameter ones for better performance.

I have done some limited efforts in making the threadsinfo implementation a bit more generic for the uses in tracing: c74eaa2

Implementation-wise it'd be a matter of further refactoring to extract the code that populates the threadinfo_t for a given thread to a separate function that accepts optional per-parameter masks and extending the threadsinfo signature to allow for these masks. The already present n arg could be e.g. set to -1 to call threadsinfo in per-thread mode.

[oI0ck]

Good point.

I think it's safe then to close this PR and tackle this matter in another one, since that's concerns a different change.