hal: compile hal_timerSetWakeup only when implemented

[julianuziemblo]

_threads_updateWakeup (the only user of hal_timerSetWakeup) does anything only if hal_timerSetWakeup is implemented to do anything. Else, it just queries the tree for no reason. This commit introduces CPU_SUPPORTS_TIMER_WAKEUP symbol to define _threads_updateWakeup only if the wakeup is suppored to eliminate unnecessary tree searches

Description

Motivation and Context

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: (list targets here).

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 (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[gemini-code-assist]

Code Review

This pull request introduces the CPU_SUPPORTS_TIMER_WAKEUP macro across various hardware abstraction layer (HAL) configurations to indicate whether a specific architecture supports timer-based wakeup functionality. It cleans up the codebase by removing non-functional stubs of hal_timerSetWakeup and uses conditional compilation in hal/timer.h and proc/threads.c to handle architectures without this support. I have no feedback to provide.

[agkaminski]

This change is kinda against our generic guidelines, i.e. only introduce ifdefs if there's no other way

[github-actions]

Unit Test Results

10 543 tests  ±0   9 881 ✅ ±0   53m 18s ⏱️ +4s
   649 suites ±0     662 💤 ±0 
     1 files   ±0       0 ❌ ±0 

Results for commit 6c15417. ± Comparison against base commit 3381cc0.

[julianuziemblo]

This change is kinda against our generic guidelines, i.e. only introduce ifdefs if there's no other way

Technically there is no other way to avoid "mindless" tree searches, but I get what you mean. Still, I'd argue we should keep this change or a similar one that removes the unneeded action.

[nalajcie]

This change is kinda against our generic guidelines, i.e. only introduce ifdefs if there's no other way

Technically there is no other way to avoid "mindless" tree searches, but I get what you mean. Still, I'd argue we should keep this change or a similar one that removes the unneeded action.

-flto would take care of that (cross-compilation-unit dead code elimination) if the function really doesn't have side effects (sometimes gcc might get confused about some code, we might want to make it a little easier for him by using eg. __attribute__((pure)) in the future).