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.
@schveiguy I think that the description and implementation jive just fine. The implementation is taking the normal approach of erroring out on new systems so that the developers there are forced to make the correct decision for that platform (either add the coarse clock if there is one or provide a branch of the implementation for that platform which doesn't use the coarse clock). From the user's perspective, the coarse clock may or may not work on the new system, but the developer is forced to deal with it.

The alternative is to just not provide a coarse clock on new platforms unless someone realizes on their own that it's an issue and implements it for that platform, and that's not normally how we deal with new platforms. In this case, it would likely mean that no new platforms would support the coarse clock even if they can and should.

As for just having unit tests, I don't see how that really tells the developers anything. At best, that means that if they're glancing through core.time and happen to see those tests and happen to wonder whether they need to do something for their specific platform and then look at the implementation and see that they do, I don't see how they're going to catch it. An explanatory comment would help with that, but they'd still have to be looking. It's common practice in druntime and Phobos to use static assertions for new platforms so that developers will know that they need to do something for that platform when it's added rather than assuming that everything is fine.

Now, I should probably rewrite this code a little so that the clock decision for `clock_gettime` is made in the version branches rather than in the call to `clock_gettime` so that it's easier to add a new POSIX platform with no coarse clock and so that other clocks can be added to specific platforms more easily later if we decide to do that, but I think that the basic approach here is fine and that it's in line with how we normally do things. The fact that the description says that the coarse clock is not necessarily supported doesn't really matter insofar as the developers have to figure out whether it's appropriate for the new system regardless, and without the assertion, they won't catch that.