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.
Oh, yuck beyond yuck. I forgot that Linux was giving a struct, and `tv_sec` is `time_t`, so it's `c_long` and therefore signed. And as you point out, because it's in two parts, it can hold more time than `long` or `ulong` can alone. And because `clock_gettime` is used for more than just the monotonic clock, and C doesn't have function overloading, they made the annoying choice of making it so that you don't even get the result in ticks. *sigh*

Well, holding the time using the system's representation is simple enough, but it doesn't jive with the `ticks` property very well. It would be pretty ugly for that to return something different depending on the OS. I suppose that we could do something like

    struct MonoTick
    {
        (u)long seconds;  // full seconds
        (u)long ticks;  // ticks less than a second
    }

and have `ticks` return that. It would then work for all of the platforms (much as it's definitely more user-friendly to return a `(u)long`). We could then either use that type internally to `MonoTime` or hold the time in the system-specific types and convert that to `MonoTick` when `ticks`  is called.

I'll have to work through that to figure out exactly what makes the most sense, but I think that the basic idea is workable, and I'm not sure how else we can deal with the full range of values for all of the OSes as well as deal with wrapping.

One nice thing about this whole discussion is that we seem to be coming up with a solution that's actually much more robust with regards to the differences between OSes and possible wrapping than `TickDuration` is. My original plan for this was cleaner than `TickDuration` (particularly since it made it so that a monotonic duration and time were no longer conflated in a single type), but its accuracy and correctness was basically the same. However, it looks like this will turn out to be much better with regards to those nasty corner cases. Thanks for pointing out some of these items that I missed. This solution will be much better for it.