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.
> I just checked, and you are right. I didn't realize this! I thought time_t was 4 bytes but it's 8 bytes on my linux 64 bit VM.

It's 32 bits on a 32-bit system and 64 bits on a 64-bit system - unless you're on Windows and you define a macro that sets it to 64 bits on a 32-bit system (though D doesn't really support that).

> Note that the tv_nsec will be nanoseconds, no matter what the resolution allows.

Yes, so they're potentially truncating the value, but we can't do anything about that. Converting it back to the correct resolution shouldn't lose anything more though. And by using ticks instead of nsecs, it works with the other platforms without truncating them prior to doing the conversions for `Duration`.

> So this also changes the game quite a bit in terms of wrapping (or to put it another way, at 580 billion years, 2^64 seconds will never wrap for all intents and purposes). Although we still do have to support 32-bit OSes, so there is that...

Yeah, though there's no guarantee the the wrap point will be when the `time_t` is full, since they could theoretically be holding this in single integral value internally and just converting it to a `timespec` for the API. But if they actually go for the whole `time_t`, then they'll never wrap. The other OSes stand a higher chance of wrapping - though if I do the math on those again, `long` would appear to be able to hold about 2924 years (ignoring leap years) with nsec precision (and `ulong` can hold about 5849). So, maybe wrapping really isn't an issue. OSX uses a `ulong` and Windows uses a `LARGE_INTEGER` which would seem to be more or less equivalent to `long`, and those don't vary between 32-bit and 64-bit, I don't think. So, the only place where 32-bit would be an issue would be POSIX, and with seconds, that gives us approximately 68 years (ignoring leap years). So, if I've got the math right this time, the only reasons that we'd realistically have to worry about wrapping is if the clock does not start at zero or if we use an unsigned value, and your subtraction example results in wrapping. Unfortunately, we have no guarantee that the clock starts at zero (either when the program starts or when the computer boots up), and if clocks in the future end up with better precision than nsecs, then we'd that would also potentially make it so that we'd have to worry about wrapping.

So, if we assume that the clock starts at zero (or close enough that it doesn't really matter) and that we don't have to worry about precision better than nsecs, then we can use a a single `long` or `ulong` to hold the ticks, and we shouldn't have any problems with wrapping beyond the user subtracting from an early clock value. But if we want to be robust against the clock starting anywhere within its possible range or about precision higher than nsecs, then we'd have to split out the seconds to cover the whole range that POSIX can cover and make sure that we can handle the clock wrapping.

So, we _probably_ could get away with not worrying about the clock wrapping, but if we want to be sure, we have to go with the more complex solution of splitting the seconds out (which for better or worse, I have most of the way implemented already). This would be a much easier decision if these APIs would just guarantee that the clock started at zero - be it at boot up time or at program startup - but they don't. I'm tempted to just go with splitting out the seconds to get the extra robustness just so that we don't have to worry about it (especially if there's any concern that computer clocks will get more precise), but I'll have to think about it some more.