add specialization for 24MHz QueryPerformanceFrequency

[fsb4000]

Fixes #3828

Fixes partially #3834

If I do

#define _LIKELY_ARM [[likely]]
#define _LIKELY_X86 [[unlikely]]
...
if (_Freq == _TenMHz) _LIKELY_X86 {
    static_assert(period::den % _TenMHz == 0, "It should never fail.");
    constexpr long long _Multiplier = period::den / _TenMHz;
    return time_point(duration(_Ctr * _Multiplier));
}
...

then clang-format format the code this way:

#define _LIKELY_ARM [[likely]]
#define _LIKELY_X86 [[unlikely]]
...

if (_Freq == _TenMHz) {
    _LIKELY_X86 {
        static_assert(period::den % _TenMHz == 0, "It should never fail.");
        constexpr long long _Multiplier = period::den / _TenMHz;
        return time_point(duration(_Ctr * _Multiplier));
    }
}

I'm not sure how well the Microsoft Visual C++ compiler's optimizer handles this, but clang-cl does a great job with inlining and simplfying the integer divisions into shifts and multiplies.

A repro that the MSVC compiler simplfying the integer divisions into shifts and multiplies: https://godbolt.org/z/zb5fob6xc

[strega-nil-ms]

Do we need to do the push_macro/undef/pop_macro magic incantation here for likely and unlikely?

[StephanTLavavej]

likely and unlikely are commonly defined as function-like macros, but not object-like macros. <xkeycheck.h> avoids rejecting them for that reason.

Unlike msvc etc., users are technically not supposed to macroize likely and unlikely, so we technically don't need to defend against them. We could but I don't think it's necessary at the moment.

[StephanTLavavej]

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

[StephanTLavavej]

Thanks for implementing this performance improvement! 🚀 🐇 🐆