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, if wrapping is a real concern, then we're going to have to use `ulong`. The reasons for that being

1. Wrapping is undefined for signed integers for both C and D. Wrapping unsigned values _is_ defined - both for C and D.
2. The POSIX systems are all returning `ulong` rather than `long`, so if we use `long`, we can't cover the whole range of values that they can return. Windows uses a `long` unfortunately, but since wrapping to negative numbers is undefined, they're going to have to go back to `0` after hitting `long.max` if they're going to work properly anyway. So, presumably, using a `ulong` will work with Windows.

And if we used `ulong`, then the subtraction will just work automagically when wrapping occurs. That does make `opCmp` a bit entertaining though. The way that I've seen it done before is to do the subtraction and then see if it's greater than half the value range, and if it is, then presumably it wrapped (either that, or the value was kept around for a _very_ long time, but if that's the case, you'll run into problems as soon as it wraps all the way around anyway). And in that case, we'd definitely want `opCmp` rather than expecting folks to do the subtraction, since getting that right becomes much more subtle.

I hate having to worry about wrapping, but it is true that if the precision gets high enough, it can become an issue, and while AFAIK, all systems start their clock at 0 when they boot, that doesn't appear to actually be guaranteed anywhere. And aside from `opCmp`, it actually works quite well (and `opCmp` can be made to work; it's just uglier than would be desirable).

One of my ex-coworkers wrote [this blog post](http://tdistler.com/2010/06/27/high-performance-timing-on-linux-windows) on high performance timing, and it basically argues for using an unsigned value in order to properly deal with wrapping, though it doesn't actually show or cite any evidence that wrapping is likely to occur.