Improve fault tolerance during PHD2 interactions

This MR builds over PHD2 tests to improve fault tolerance. Tested workarounds in the following situations:

• Star does not move enough for calibration to complete. PHD2 may:
  • be looping instead of calibrating, while still notifying calibration.
  • abort but continue to send guide steps and frames.
  • => Fixed: calibration failures are now properly handled in that situation, and forwarded to Guide module.
• Star disappears because of a mount glitch. PHD2 may:
  • declare star lost and stop without further notice.
  • => Fixed: star-lost notification is now properly handled, and will time out properly (and not restart).
• Device disconnects briefly. PHD2 may:
  • declare device unusable, eventually after some time (camera timeout is 15s by default), requiring reconnect.
  • => Fixed: equipment dis/connection is now properly handled from both sides, aborts operations and is robust.
• KStars/Ekos crashes while guiding and is restarted using the existing indiserver.
  • The currentCCD may be null when restoring connection, upon call to executeOneOperation.
  • AppState has to be taken into consideration to restore state as it was before the crash.
  • => Fixed: app-state polling improves robustness, requires up-to-date INDI build.
• If Ekos is told the equipment is disconnected, it will consider an external cause and will not attempt to reconnect.
  • Ekos will not reconnect, to allow manual intervention is required on PHD2 side.
  • Ekos will detect reconnection and change state automatically.
• However PHD2 v2.6.8 crashes when INDI drivers are killed, so no solution except restarting PHD2 in a loop (use systemd).
• One issue remains in Guide, where the stop button remains enabled sometimes (regression?).
  • May not fix in the context of this MR.
• One issue remains upon server loss, which triggers perpetual reconnect unless the end-user disconnects manually.
  • Issue related to state kept at disconnected.

This MR also adds three KLeds to the Guide module for visual feedback, which turn yellow/green/red based on state. The nominal sequence is for the three leds to turn yellow then green one after the other.

This now requires thorough testing with various user configurations.