Replace std::system_clock with std::steady_clock

[calcmogul]

There's several places that should use std::steady_clock for monotonicity. I'm not sure what we should do for thirdparty deps.

[tav@myriad allwpilib]$ rg system_clock
thirdparty/googletest/src/googletest/src/gtest.cpp
1161:  // Fall back to the system_clock when building with newlib on a system
1164:  using clock = std::chrono::system_clock;
1176:             std::chrono::system_clock::now() -
1177:             std::chrono::system_clock::from_time_t(0))

wpiutil/src/test/native/cpp/priority_mutex_test.cpp
17:using std::chrono::system_clock;
105:    system_clock::time_point start_time = system_clock::now();
110:      if (system_clock::now() - start_time > std::chrono::milliseconds(50)) {

wpilibc/src/main/native/cpp/Timer.cpp
22:  using std::chrono::system_clock;
25:      duration_cast<duration<double>>(system_clock::now().time_since_epoch())

wpiutil/src/main/native/thirdparty/llvm/include/wpi/Chrono.h
31:/// on a clock other than the system_clock, use std::chrono directly.
33:using TimePoint = std::chrono::time_point<std::chrono::system_clock, D>;
37:class UtcClock : public std::chrono::system_clock {};
51:  return system_clock::to_time_t(
52:      time_point_cast<system_clock::time_point::duration>(TP));
58:  return system_clock::to_time_t(time_point<system_clock, seconds>(
66:  return time_point_cast<seconds>(system_clock::from_time_t(T));
73:  return time_point_cast<nanoseconds>(system_clock::from_time_t(T))

upstream_utils/llvm_patches/0007-Remove-format_provider.patch
180:-      system_clock::from_time_t(mktime(&TM)) + nanoseconds(123456789);
182:-      system_clock::from_time_t(mktime(&TM)) + nanoseconds(23456789);

wpiutil/src/main/native/thirdparty/fmtlib/include/fmt/chrono.h
29:      -> std::chrono::time_point<std::chrono::system_clock, Duration> {
285:using sys_time = std::chrono::time_point<std::chrono::system_clock, Duration>;
514:  // Cannot use std::chrono::system_clock::to_time_t since this would first
515:  // require a cast to std::chrono::system_clock::time_point, which could

wpiutil/src/main/native/cpp/timestamp.cpp
44:             std::chrono::system_clock::now().time_since_epoch())

wpimath/src/main/native/thirdparty/sleipnir/include/sleipnir/autodiff/Profiler.hpp
20:  void StartSetup() { m_setupStartTime = std::chrono::system_clock::now(); }
26:    m_setupDuration = std::chrono::system_clock::now() - m_setupStartTime;
32:  void StartSolve() { m_solveStartTime = std::chrono::system_clock::now(); }
39:    auto now = std::chrono::system_clock::now();
71:  std::chrono::system_clock::time_point m_setupStartTime;
76:  std::chrono::system_clock::time_point m_solveStartTime;

wpimath/src/main/native/thirdparty/sleipnir/src/optimization/solver/SQP.cpp
37:  const auto solveStartTime = std::chrono::system_clock::now();
113:  std::chrono::system_clock::time_point iterationsStartTime;
122:      auto solveEndTime = std::chrono::system_clock::now();
172:    iterationsStartTime = std::chrono::system_clock::now();
177:    std::chrono::system_clock::time_point innerIterStartTime;
179:      innerIterStartTime = std::chrono::system_clock::now();
521:    const auto innerIterEndTime = std::chrono::system_clock::now();

wpimath/src/main/native/thirdparty/sleipnir/src/optimization/solver/InteriorPoint.cpp
44:  const auto solveStartTime = std::chrono::system_clock::now();
140:  std::chrono::system_clock::time_point iterationsStartTime;
149:      auto solveEndTime = std::chrono::system_clock::now();
244:    iterationsStartTime = std::chrono::system_clock::now();
249:    std::chrono::system_clock::time_point innerIterStartTime;
251:      innerIterStartTime = std::chrono::system_clock::now();
787:    const auto innerIterEndTime = std::chrono::system_clock::now();

[KangarooKoala]

Just as a note, the std::steady_clock docs note that it's most suited for measuring durations. I'm pretty sure that's what most (if not all) of the occurrences of std::system_clock are used for, but it's still worth noting if that's not the case for a few.

[KangarooKoala]

Any particular reason to target 2027? (There isn't a particular reason to target main for 2026 either, I'm just curious since this shouldn't be an API-breaking change)

[calcmogul]

It's not an API-breaking change, but it's a behavior-breaking change.