Skip the timestamp write checks for a locked clock

[glopesdev]

The two checks that write R_TIMESTAMP_SECOND now read R_CLOCK_CONFIG first and skip when the device reports CLK_LOCK, since a device with a locked timestamp register is correct to refuse the write. Without the guard such a device would report two errors, and because the exit code counts errors as well as failures, the whole run would exit 1.

The guard is conservative in two directions, both deliberate. It skips only on a positive CLK_LOCK, so a device that reports neither lock bit still runs both checks. And a failed read of R_CLOCK_CONFIG counts as not locked, since the register is only RECOMMENDED and a device that does not implement it has no lock state. Skipped is the right status because the checks are in scope and did not run, which is how ClockTestSuite already reports a missing --clock-port.

Verified on hardware

Measured against a Behavior device on firmware 3.2, which supports locking and reports it conformantly, reading 0x40 unlocked and 0x80 locked.

arm	outcome	exit
locked, without this change	22 passed, 2 error, 4 skipped	1
locked, with this change	22 passed, 6 skipped	0
unlocked, with this change	24 passed, 4 skipped	0

The unlocked run is identical to the one before this change, so the guard does nothing on a device that is not locked.

[bruno-f-cruz]

I think we should consider moving this test here

https://github.com/harp-tech/toolkit/blob/main/src/Harp.Toolkit/Verify/Suites/CoreRegisters/R_CLOCK_CONFIG.cs

And report the functionality. In other words, it should become two tests:

1. Check if the clock is lockable/unlockable by writing to the register and listening for errors/returned value

2. Test if the 2 modes are correctly implemented, depending on the previous test

[glopesdev]

@bruno-f-cruz Agreed, that will be a follow-up PR which I already have and will commit after rebase.