<__msvc_chrono.hpp>: Use _Xtime_get_ticks in _To_timespec64_sys_10_day_clamped for consistency

[statementreply]

Part of #1588.

_Xtime_get_ticks and system_clock::now would no longer be equal after a future leap second when #1520 is eventually fixed. This PR changes the clock used in _To_timespec64_sys_10_day_clamped to be consistent with code that consumes its result, e.g. target in

STL/stl/src/cond.cpp

Lines 72 to 80 in 091cad2

	_timespec64 now;
	_Timespec64_get_sys(&now);
	_Mtx_clear_owner(mtx);
	if (!cond->_get_cv()->wait_for(cs, _Xtime_diff_to_millis2(target, &now))) { // report timeout
	_Timespec64_get_sys(&now);
	if (_Xtime_diff_to_millis2(target, &now) == 0) {
	res = _Thrd_timedout;
	}
	}

@BillyONeal pointed out (on Discord) that this PR could break (already somewhat broken) timed wait ABI:

_To_xtime_10_day_clamped, used by condition_variable::wait_for, this_thread::sleep_for, etc., calls system_clock::now() internally to compute a value interpreted as GetSystemTimeAsFileTime + offset by another component. My understanding is that if the linker picks the old version of _To_xtime_10_day_clamped and the new version of system_clock::now() from different object files, all those wait functions could wait for a few seconds too short (assuming positive leap seconds) after future leap seconds.

[StephanTLavavej]

Looks good to me - no behavioral change now, and the consistency argument for the future is convincing. Thanks!

[StephanTLavavej]

I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[CaseyCarter]

Thanks for fixing this future bug before we could write it! 🕦 🕐 🕙 🕥 🕚