Propagate per-sample hardware timestamps through the signal chain

[anjaldoshi]

Preserves per-sample timestamps through processing and recording for hardware-synced streams. Previously, timestamps were reduced to the first sample per block and the rest inferred, which could cause drift or backward jumps when the effective rate varied.

• DataBuffer::readAllFromBuffer() now returns full per-sample timestamps.
• Added SystemEvent::TIMESTAMP_ARRAY to propagate timestamps without altering existing formats.
• SourceNode now buffers and emits per-sample timestamps alongside legacy metadata.
• Added GenericProcessor helpers for accessing and resolving timestamps within a block.
• Updated RecordNode to use per-sample timestamps, with interpolation as fallback.
• DataQueue can now write timestamp arrays directly.
• Extended unit tests and added regression tests for timestamp handling.
• Existing event paths unchanged.
• No virtual method or layout changes to exported APIs to preserve backward compatibility.

[bparks13]

Tested this with the ONIX Source plugin, where the expected sample rate was manipulated to be well over or well under the actual sample rate. I also recorded the timestamps manually next to the binary files, and compared the recorded timestamps to the manually saved timestamps. In all cases, the timestamps were correctly propagated to the binary files and saved, even in extreme cases where the expected sample rate was > 1 kHz off from the real sample rate. The mean difference between the manually saved timestamps and the recorded timestamps was 2.704472865532025e-07 seconds, which is most likely due to rounding errors since these are double values.