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.
> What types of potential failures do you foresee?

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.

> It would be very bad for instance if the coarse clock returned a completely different value than the the normal clock

I don't know if we need to guarantee this possibility. Although it may be the case today, we are not in control of the meaning of these two clocks, and this can possibly change (very unlikely), or on a new system (non- linux or freebsd), there are two possible clocks, one "quick", and one "slow" to retrieve, but they are not related to each other.

I think the only thing we need to guarantee is that fetching two times from the same clock source is sane. I'd almost recommend putting a sleep in between those calls, and dropping the = part of <=.

> though maybe the solution to that is to add the clock type to MonoTime internally and throw an Error if MonoTimes with different clock types are compared...

I don't like that, this introduces another possible runtime check, and possibly another member to the struct.

Overall, I'm not vehemently opposed to the tests, I just was pointing out possible issues with them. In any case, unit testing time features is going to largely depend on the behavior of the OS, over which we have 0 control.