Start improving high-throughput multi-camera recording path and diagnostics

[C-Achard]

Summary

Improves multi-camera recording behavior under high-throughput conditions by separating recording frame delivery from the heavier GUI/DLC processing path, adding clearer recorder backlog/queue diagnostics, and introducing an optional faster encoding mode for supported FFmpeg codecs.
This is a first quick remediation to the deeper architectural concern requiring the recording to be moved closer to camera SDK frame grabbing.

Main changes

1. Adds a dedicated recording_frame_ready(camera_id, frame, timestamp) signal for full-rate recording frames.
2. Recording frames are now handled by a lean recording-only path instead of _on_multi_frame_processing_ready().
3. Recording-frame emission is disabled by default and only enabled while recording is active.
4. Adds a "Use faster encoding" parameters checkbox in the Recording panel.
   For libx264/libx265, this applies:
   • Preset ultrafast
   • Tune zerolatency
5. Centralizes WriteGear/FFmpeg option generation in RecordingSettings.writegear_options().
6. Adds recorder better diagnostics
7. Updates multi-camera recorder summaries to aggregate queue/backlog/writer throughput across cameras.
8. Switches Basler grabbing to GrabStrategy_OneByOne so recording-oriented acquisition does not silently prefer only the latest image.
9. Reduces noisy Basler trigger debug logs behind an explicit DEBUG_TRIGGER_LOGS flag.
10. Adds profiling artifacts to .gitignore.
11. Updates tests for the new recording signal, fast encoding options, recorder stats formatting, and multi-camera recording aggregation.

What this improves

This makes it easier to diagnose when the recorder is falling behind before drops occur. Previously, dropped = 0 could hide the fact that recorder queues were filling. The new stats expose that state directly through queue fill and backlog.
The fast encoding option also provides a user-controlled way to trade compression efficiency/file size for higher recording throughput.

Not solved yet

• Recording frames still pass through the Qt/main-window path before reaching VideoRecorder.write().
• The actual encoder write is already threaded, but the producer/enqueue side can still add main-thread pressure at very high frame rates.
• This PR does not introduce a dedicated recording router thread or direct camera-worker-to-recorder routing.
• This does not guarantee full-rate recording for extreme cases, but makes bottlenecks more visible and improves slightly the x264 fast path at the cost of worst file size.

Testing

Added/updated unit tests for:

• Recording-frame signal enable/disable behavior
• Recording overlay routing
• RecordingSettings.writegear_options()
• Fast encoding option propagation
• Recorder queue/backlog stats formatting
• Multi-recorder stats aggregation

---

• Note before merge: disable debug logging