Fix CPU timing infrastructure

[charmoniumQ]

• The existing infrastructure does not record data if the shutdown is not clean. This means a small bug in the destructor totally disrupts the experiment.
• The existing infrastructure does not capture response-time or latency, except for hardcoded channels.
• The existing infrastructure does not capture the stack, so it cannot reconstruct the callgraph, without manual instruction.
• The existing infrastructure is not thread safe: lines could get spliced in the log.
• The existing infrastructure uses a different collection method for ILLIXR-native components, external components such as OpenVINS, and libraries such as OpenCV.
• The existing infrastructure is limited to capturing at a specific level: a plugin's _p_one_iteration or switchboard callback. This necessitates a lot of complex, hardcoded logic in the analysis scripts. This complexity was error-prone (this is why periods were wrong in OpenVINS when I was showing it during the scheduling meeting).
  • It requires hardcoded logic to split offline_imu_cam and OpenVINS into the times it had camera data vs just IMU data.
  • It requires hardcoded logic to sum OpenVINS's component threads (durations should be summed, but what about start times?).
  • It requires hardcoded logic to extract the logging overhead time.
• The existing infrastructure cannot distinguish when component A calls a library function that starts a thread and when B calls the same function. Since it starts a thread, its CPU time won't be accounted in A and B. This gives us trouble in the existing infrastructure that OpenVINS and the camera loader both called OpenCV.

Also see #211.