Reported resolution of `time.process_time` and `time.thread_time` is wrong on Windows

Bug report

Bug description:

>>> import time
>>> time.get_clock_info("process_time")
namespace(implementation='GetProcessTimes()', monotonic=True, adjustable=False, resolution=1e-07)
>>> time.get_clock_info("thread_time")
namespace(implementation='GetThreadTimes()', monotonic=True, adjustable=False, resolution=1e-07)

The reported resolution=1e-07 is way off. According to @eryksun in https://github.com/python/cpython/issues/82040#issuecomment-1093831784

Don't read too much into the clock info here:
Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). But the kernel schedules threads based on a timer that ticks every 15.625 ms by default. It can be lowered to about 0.5 ms, but this degrades battery life.

This has also caused problems in test_int.test_denial_of_service, see https://github.com/python/cpython/issues/114911#issuecomment-2567094984.

I suggest to report 15.625 ms, since this is the upper limit.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-135305

Begin by reviewing linked PR gh-135305 and the behavior of time.get_clock_info("process_time") and time.get_clock_info("thread_time") on Windows. Check test_int.test_denial_of_service for the related impact; done means the reported resolutions reflect the intended Windows timing behavior and the affected test passes.