fix: PCAP traces have wrong timestamps

[KonradBreitsprecherBkd]

The PCAP sink writes the nanosecond magic number (0xa1b23c4d) into the global header, but it wrote the packet timestamps in microseconds. Wireshark, tcpdump and every other PCAP consumer trust the magic number, so they showed the decimal places of all timestamps 1000 times too small (The seconds are treated seperately, so this was correct and likely the cause why this was overlooked). SIL Kit's own PcapReader hid the problem because it made the same mistake the other way round and always read the field as microseconds.

I confirmed this with a PCAP export from SIL Kit: A frame sent at T=6782 ms has ts_sec=6, ts_usec=782000, and Wireshark shows it as 6.000782 s instead of 6.782 s. With the fix here, the timestamps in the wireshark trace match the SIL Kit logs.
To reproduce use this config for the EthernetWriterDemo, look at the last timestamp in the log and compare it to the timestamp in wireshark :

Description: PCAP tracing configuration for the EthernetWriter demo
EthernetControllers:
  - Name: EthernetController1
    UseTraceSinks: [ PcapSink ]
Tracing:
  TraceSinks:
    - Name: PcapSink
      Type: PcapFile
      OutputPath: EthernetWriter_Trace.pcap
Logging:
  Sinks:
    - Type: Stdout
      Level: Info

This PR makes both sides follow the magic number:

• Sink: packet timestamps are now written in nanoseconds, which matches the announced resolution.
• Reader: it reads the resolution from the magic number. Besides nanosecond files it now also accepts microsecond files (0xa1b2c3d4), so captures made with Wireshark or tcpdump can be replayed.
• PacketHeader::ts_usec is renamed to ts_fraction, because its unit depends on the magic number.

Compatibility: .pcap files written by earlier SIL Kit versions contain microseconds under the nanosecond magic. From now on, PcapReader reads their timestamps 1000 times too small, which is how every other PCAP tool already read them. Replaying such old traces will show compressed timing.

Instructions for review / testing

• Main change: PcapSink::Trace (SilKit/source/tracing/PcapSink.cpp) and PcapReader::ReadGlobalHeader / Seek (SilKit/source/tracing/PcapReader.cpp).
• Please check the compatibility trade-off above. The alternative would be to keep writing microseconds and switch the magic number to 0xa1b2c3d4 instead. That keeps old files readable, but traces lose sub-microsecond precision.
• Manual check: record an Ethernet trace with a PcapFile sink, open it in Wireshark, and confirm the timestamps match the simulation time.

Developer checklist (address before review)

• Changelog.md updated
• Prepared update for depending repositories
• Documentation updated (public API changes only)
• API docstrings updated (public API changes only)
• Rebase → commit history clean
• Squash and merge → proper PR title

[VDanielEdwards]

We could add

• a enum struct TimestampMode with two enumerators Nanoseconds and Microseconds
• and a method GetTimestampMode() const -> TimestampMode that compares the magic number

That makes it simpler for code using the PacketHeader structure to get that info without having to know about the magic numbers.

[KonradBreitsprecherBkd]

The magicNumber lives in GlobalHeader, I added GetTimestampMode there.

[MariusBgm]

i think we should keep this code as simple as possible, and just support microseconds, and clamp the timestamps appropriately

[KonradBreitsprecherBkd]

I'd say the error handling to check for the MicrosecondMagic only in the header and return an error is just as complicated as supporting both cases.

[VDanielEdwards]

Is there a downside to using nanoseconds? Since SIL Kit timestamps are nanoseconds that seems like the more natural choice for us.

Also since we can also read PCAP files for replay, shouldn't we support both, since we could get a file that was recorded, e.g., using tcpdump.