[Windows] One TimeTicks clock: efficient/reliable high-res, with low-res fallback.

This change resolves a critical issue where two different clocks' values
were being mixed in computations involving TimeTicks for ~32% of users
on Windows. The solution is to force the use of a single clock for
TimeTicks::Now() and HighResNow(). In other words, we're moving towards
a world where the TimeTicks type should guarantee all time values are on
the same timeline.

New behavior: On systems where QPC is reliable AND efficient, Now() will
simply use the QPC clock. This is consistent with how Now() behaves on
the Mac and POSIX platforms. However, if QPC is working but is
inefficient, Now() will use the low-res clock. Finally, like before, if
the QPC is not working on the current system, Now() will use the low-res
clock.

NowFromSystemTraceTime() will always use the QPC clock if it is
working, just as before, and regardless of whether it is expensive to
use. This is to ensure tracing data remains useful. When QPC uses either
HPET or ACPI PM as a clock source, online literature suggests clock
sampling will be ~20 to ~40 times as costly (about 1.2 to 2.4us per
call).

Note: From discussion with stakeholders, there is a concern this change
will increase latency and jitter in the compositor pipeline on the
affected Windows machines. Future changes will take alternate approaches
to resolve these problems.

Note 2: This change minimizes TimeTicks API changes, in favor of future
clean-up changes.

BUG=396384,435931,439656

Review URL: https://codereview.chromium.org/797893003

Cr-Commit-Position: refs/heads/master@{#311414}
7 files changed