Move microcontroller message handling to own thread

[Short-bus]

UART comms are handled by own thread, but that just deals with the communication, it buffers the messages between RPi and Microcontroller. The actual handling of the messages sent/received is currently handled in one of three loops. 1) GoTo loop. 2) Tune loop. 3) ObservationRun loop. Originally these loops behaved very differently, but have gradually become very similar. Also the current solution means that 'configuration', 'trajectory' and 'recovery' and 'status' tasks have to be handled by the main ObservationRun loop. This loop should really just be handling the user interface.

Strip out the message handling from the three loops and consolidate into a separate thread which can run independently and ensure that the RPi / Microcontroller remain synchronised constantly in the background. This should speed up the start of observations too because much of the configuration work will be done BEFORE the observation starts.

Needs some to ensure that the motor controller knows to stop if things go wrong in the main loop.

This means there will be the main program thread plus 3 other background threads in total.

• CameraHandler (existing).
• UART communication (existing).
• Message handler (new).

It adds some complexity to handle the threads consistently, but separates the different tasks into their own process streams.

Consider reworking the dashboard 'communication' windows to reflect this new operation.

[Short-bus]

Ran observations successfully with the new solution. Will still improve the microcontroller code to be more resilient too.

[Short-bus]

Microcontroller code (code.py) now flushes any trajectory if communication is lost for 2 minutes. When comms is restored the trajectory is reloaded and movement resumes.

[Short-bus]

Summer2023 includes this new feature.