consolidate system timer handling in architectures: provide either via ARCH_TIMER/ARCH_ALARM or not, not both

The ARCH_TIMER and ARCH_ALARM drivers implement the required logic for handling NuttX system timer, both supporting the case of TICKLESS or non TICKLESS mode. These "drivers" require are based on abstract `timer_lowerhalf_s` and `oneshot_lowerhalf_s` interfaces, which the architecture can provide. Moreover, the ARM systick is already exposed as a `timer_lowerhalf_s` and thus can be automatically used for tickless/non-tickless with minimal code.
Finally, these drivers implement `up_mdelay()` using the underlying timer instead of a hardcoded loop which requires manual tuning.

EDIT: the above description reflects the current state of these drivers, but arch_alarm should **not** be based on oneshot timer as this is suboptimal. This is tracked in a separate issue: #1725.

Right now different some architectures employ this support but it is considered as an extra option and the corresponding up_timer_*/up_alarm_* interfaces, systick handling and "dumb" up_mdelay() is conditionally compiled. It would be much better to have an arch implementation decide how it will expose the system timer (either via these "drivers" or manually, if for example minimizing code size is important).

To address this issue:
- [ ] These facilities must be documented (how each driver is operated, what the architecture needs to do to use it, how kconfig defines should be used so that proper configuration is done without user having to combine appropriate options)
- [ ] The documentation should indicate that supporting both implementations in an architecture is deprecated (and thus PRs for new architectures should follow this accordingly)
- [ ] Existing architectures should slowly be changed to use either of the two approaches and not both

Related issues/PRs: #1716 #1710 #1705 (nRF52 implementation of system timer using these drivers)