Add ClockType enum to core.time for issue# 13433.

This adds an enum for indicating which type of clock to use when it's
appropriate for a time function to have multiple options for the source
clock. Currently, it only supports "normal" and "coarse," but we may add
more in the future, since some systems do support others (e.g
clock_gettime has several other options depending on the system).

This is in support of https://github.com/D-Programming-Language/phobos/pull/2584.
> We are depending on a certain execution speed. It's far-fetched, but imagine that the process is put to sleep in between reading the two clocks, and some other process hangs the OS for over 1 second. Then when it comes back, the delta between the two reads is more than 1 second, you get a failure.

Ah, true. That could definitely happen, but I'm loathe to use sleeps in general unless I have to, and I'm trying to specifically test that the clocks are very close to one another (just differing in precision, not units), so sleeps would actually defeat the purpose of the tests. So, I suspect that we're stuck the possibility of that random failure, though I think that it's unlikely - especially on the autotester where the boxes are dedicated to running the tests.

I _really_ don't like the idea of `MonoTime` being able to be backed by two completely different clocks without any way to differentiate the resulting `MonoTime`s, because that could easily lead to weird behavior and nasty bugs if the clocks are mixed. I'm okay with using the coarse clock so long as it appears to just be grabbing the time less frequently at the kernel level and thus not be as up-to-date (which seems to be what's happening on both Linux and FreeBSD), but if they're completely different timers, then that's just begging for bugs IMHO to use `MonoTime` for both without a member variable differentiating them. So, that means either creating separate types for the different clocks or adding a member variable to differentiate them. Neither choice is particularly appealing, though between the two of them, I'd much prefer the member variable route. So, to avoid that, we need to ensure that the clocks being used have the same start time and units (or very close to it anyway, since we can't actually test for that directly). Without that, I think that we need to either add a member variable indicating the clock type or to not support the coarse clock (or any clock which does not have the same start time and units). Fortunately, it looks like the coarse clock is really just the same clock as the normal one except that it's grabbing the time from a place that isn't updated as frequently, so I think that we can support the coarse clock without having to worry about mixing clocks, but I think that it's then unlikely that any of the other clock types from the specific implementations of `clock_gettime` will be supported (except maybe `CLOCK_MONOTIME_PRECISE` on FreeBSD, but I haven't been able to find any info on what's different between that and the normal clock, which is supposed to be precise already).

I should probably better comment the tests though to make the intention clear.