Bugfix: Rp2040 and Host os_timer_setfn() can stall other timers

[mikee47]

If called on first timer in queue then subsequent timers get disconnected. Must explicitly disarm the timer first so it's properly removed from queue. This is consistent with esp8266 behaviour.

Also applied to host timer from whence the code originated.
This bug might explain root cause of #2594, where code hangs during intensive timer usage. Specifically, this issue gets triggered if attempting to change the callback on an active timer. (If the timer is inactive then it's not in the queue so doesn't matter.)

[what-the-diff]

PR Summary

• Insuring Against Null Pointer in Timer Setup Function
  The team has added a safeguard in the timer setup function (os_timer_setfn). Now, if the system encounters something called a 'null pointer', it won't result in an error. This makes the overall codes safer and more robust.

• Pre-Emptive Handling of Null Pointer Scenario
  The process to handle this 'null pointer' case now occurs earlier, before the timer gets adjusted. This means potential issues are caught and addressed sooner, enhancing the system's reliability.

• Disabling Timer Before Modification
  The developers have included a new step where the timer is 'disarmed' before being modified. This scheduling tweak improves the accuracy of our timing tasks and enhances the system's performance by ensuring any modifications don't accidentally trigger the timer.