factor out thermal control loop guts into a crate that can be tested on a normal computer

It would be very useful if the core logic of the thermal control loop in the thermal task could be tested automatically without manual testing on an actual sled or Sidecar. While it would still be necessary to test the actual behavior of the thermal subsystem on physical hardware, we could verify the high-level logic of the control loop automatically on CI. Issues like the one fixed by #2395, where the fix in #2391 was accidentally undone by applying code style review feedback, could have been avoided if we had been able to write a simple regression test for the original bug. Furthermore, if we intend to make substantial changes to the thermal loop such as described in #2355, #2280, https://github.com/oxidecomputer/hubris/issues/2361#issuecomment-3781875889, and so on, having proper tests would make this much less risky. And, it would be much easier to improve PID coefficient tuning if we could run the control loop on a development system with simulated inputs.

Pulling apart the core logic into a separate crate that doesn't require Hubris-specific APIs such as performing IPCs is not going to be a small refactor. It is helped a bit by the separation between the actual control logic and "all the other stuff" such as reading sensor measurements from I2C devices, sending data to the sensors task, and setting the PWM duty cycle, but...it's still probably not going to be easy to totally separate the logic from dependencies on code that only builds for no-std ARM targets. But, it's almost certainly worth the effort as we make further changes to the thermal logic.

Start by tracing the thermal task's control-loop logic and its dependencies on Hubris-specific APIs, I2C sensor reads, IPC, and PWM output. Separate the testable core into a crate that builds on a normal computer, add automated regression tests for simulated inputs, and confirm the hardware-specific behavior remains covered separately.