Investigate fully single-threaded setup

[mifrandir]

At the moment, the pod-side code makes heavy use of threading. This makes sense because we have different components that are quite independent. However, the BBB only has a single core so we cannot make use of any parallelism whatsoever.

Further, every module has a main loop that reruns the same logic over and over again. This means it is easy break up the code into chunks that can be run consecutively without blocking each other for too long. This should lead to a speedup because we don't need to rely on the OS to switch between the threads. Further, it will allow us to use callbacks. For example, some parts of the code currently use sleeps to account for mechanical actions, like engaging brakes. Consider the following fictional code:

engageBrakes();
Thread::sleep(1000);
if (!checkBrakesEngaged()) {
  criticalFaillure("Could not engage brakes");
}

This could be improved by using a central event queue as follows:

engageBrakes()
Core::schedule(1000, [&]{
  if (checkBrakesEngaged()) {
    criticalFailure("Could not engage brakes");
  }
});

This would have several advantages:

1. Removes race conditions and make the program more deterministic.
2. Allows for simple scheduling.
3. Gives finer control in terms of priorities.
4. Reduces thread overhead and scheduling costs.
5. Allows us to get rid of singleton instances, e.g. for data and system.
6. Allows to use (const) references and modifying/reading from those directly so we save on locking.
7. Simplifies testing as we can verify properties of data after each iteration.
8. Allows us to (eventually) get rid of check based code e.g. in State Machine. Instead, we could use updates directly as everything would be in the same thread so transitions could happen instantly after a change occurs.