Add MonoTime as a replacement for TickDuration

`TickDuration` conflates a timestamp of the monotonic clock and a duration in ticks of the monotonic clock, which is causing problems and confusion. In addition, it doesn't follow the same API as Duration (since it was developed separately by SHOO), even using the same function names for different things (e.g. `Duration.msecs` gives the milliseconds split out whereas `TickDuration.msecs` gives the total in miliseconds). And IMHO, having two duration types is overly confusing anyway. By having only one duration type, it's then quite clear which duration type code should use, whereas if they're are multiple, folks then have to understand the differences between them in order to figure out which to use where.

So, I'm proposing that we add `MonoTime`. It will represent a timestamp of the monotonic clock and will have almost no functionality on it (since it doesn't usually make sense to do much directly with a timestamp of the monotontic clock). It can be compared and subtracted but not much else. When subtracting two `MonoTime`s, you'll get a `Duration`. That does result in some rounding errors (because the clock frequency is being converted to hecto-nanoseconds) and might result in lower precision (though many systems don't have a clock resolution/frequency as a high as hecto-nanoseconds anyway), but it's eminently usable and user-friendly., and most code doesn't need precision higher than hecto-nanoseconds anyway.

    immutable before = MonoTime.currTime;
    // do stuff
    immutable after = MonoTime.currTime;
    auto timeElapsed = after - before;

For those rare cases where someone needs to actually operate in system ticks, they can use the `ticks` property of a `MonoTime` and its `ticksPerSecond` property to operate in ticks like `TickDuration` would do now. But most folks shouldn't need to do that.

This should simplify things considerably. The one area that might annoy people is that `Duration` has no support for floating point calculations (whereas `TickDuration` does), but in most cases, it's a bad idea to use floating point values when dealing with time, so in most cases, people probably shouldn't be using floating point anyway. But that can be discussed separately as an enhancement to `Duration` if it's deemed appropriate. `MonoTime` itself doesn't care.

For now, `TickDuration` has not been deprecated, because it's still used by the benchmarking functions in std.datetime. However, when I split std.datetime (which should be happening soon), I intend to create versions of those functions which use `Duration`, and put them in std.benchmark, where they're supposed to eventually end up anyway (but haven't due to issues with implementing std.benchmark). The old versions of those functions which use `TickDuration`, along with `TickDuration`, itself can then be deprecated.

I have however removed the few uses of `TickDuration` in druntime outside of core.time with this pull.
Well, looking at what each of the autotester boxes prints out for `MonoTime.currTime`, the largest value is just over 9 weeks, and the smallest is a little over a day, so I'd say that it's safe to say that all of the platforms that dmd currently targets start their monotonic clock at 0 when the system boots up. So, unless we're concerned about other systems that gdc or ldc would support doing something different, I think that the reality of the matter is that we don't have to worry about the monotonic clock starting at anything other than 0 at system startup, and the largest that any program will see is the time since the system booted, which would likely never reach more than a few years.

At nanosecond resolution, `long` gives us approximately 2924 years, and `ulong` gives us approximately 5849 years, and that's probably the largest precision that we're going to see at this point (it's certainly the largest that POSIX can do given its API). But even if a clock had picosecond resolution, and we could get that from the C API, we'd still have just under 3 years with `long` and just under 6 years with `ulong`.

So, realistically, I think that both `long` and `ulong` for holding the ticks as a single integral value will work, and we don't have to worry about wrapping. So, while my foray into figuring out how to deal with wrapping and supporting the full resolution of all of the various systems' clocks was interesting, I don't think that we need to go that route. It appears to complicate things without any real benefit.

So, I'll look over the code again and make any adjustments that seem appropriate based on any of the previous comments or on what I've figured out since, and then it'll either be `long` or `ulong`, depending on what makes the most sense (probably `long`, since we're not going to worry about wrapping), and then hopefully we can look at getting this merged.