🐛 fix sudden grbl reset upon hard limit trigger

When an hard limit is triggered, the limit_interrupt_handler ISR is executed and it may be performed from a different thread than the "main" one.

So, a race condition may occur as the limit_interrupt_handler set the flag for the sys reset (mc_reset()) before setting the Alarm_HardLimit flag (system_set_exec_alarm(Alarm_HardLimit)) and the main thread may get to process the reset request before the Alarm_HardLimit flag gets set (here) instead of going through the typical path.

Thus, a solution could be to check if there are pending critical alarms (e.g. hard and soft limit alarm) before brutally aborting (-> resetting) Grbl and preventing them from being properly treated. The pending alarms will be processed in the next call of protocol_exec_rt_system, which is invoked in different points in the main program.