Recording and trigger mode improvements #83

Context

Several improvements could still be made to the GUI, notably regarding performance and task distribution.
Recent changes (e.g. #82) significantly improved recording performance for monochrome Basler cameras by avoiding unnecessary Mono8 → BGR8 casting. However, for high-throughput multi-camera setups recording can still lose frames, especially with multiple cameras at high FPS/resolution.

• Making the current data processing pipeline less sequential

Currently it consists of:

camera backend read
→ SingleCameraWorker signal
→ MultiCameraController full-rate slot
→ MultiFrameData construction
→ GUI full-rate frame handler
→ RecordingManager
→ VideoRecorder queue
→ writer thread / WriteGear

The main goals there would be to have:

• Separate acquisition from downstream processing as much as possible
• Ensure recording, display, and DLC have independent queue& drop behavior
• Ensure the camera grabbing path does minimal work, e.g.:
  • Retrieve frame
  • Timestamp
  • Minimal metadata
  • Enqueue/dispatch quickly

• Ensuring triggered cams are started/stopped properly in regards to recording
  • Start: all followers → master → recording
  • Stop: master → followers stop → finish queues → stop recording