Add Stopwatch.GetElapsedTime

[stephentoub]

Fixes #65858

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[am11]

An unrelated question about s_tickFrequency
On Unix, we use a constant 1000000000 for frequency calculation, while on Windows we call Kernel32.QueryPerformanceFrequency()). Would it make sense to align them? e.g. making it constant for Windows as well, or implementing frequency shim on Unix; something like:

int64_t SystemNative_GetPerformanceCounterFrequency()
{
    const int64_t defaultFrequency = 1000000000;

    struct timespec spec;
    if (clock_getres(CLOCK_MONOTONIC, &spec) != 0) return defaultFrequency;

    assert(spec.tv_sec < 1); // resolution in seconds is too high to be correct
    assert(spec.tv_nsec > 0);

    return defaultFrequency / spec.tv_nsec;
}

[stephentoub]

It used to call into a native shim. It was changed in #43343.

[tannergooding]

For reference, Unix always returns something in terms of seconds + nanoseconds. Where-as Windows returns a measurement in unknown units where you have to independently query a frequency to convert it to nanoseconds.

The static APIs on Stopwatch are meant to be minimal overhead and directly return the "raw units" given by the underlying OS functions. This new helper is what allows it to be normalized to TimeSpan units, which are in terms of 100ns ticks.