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.
What I've been looking at doing is adding a `seconds` property to `MonoTime`, which returns the number of full seconds that have past, and then make the `ticks` property just return the ticks past the second. Then, we get the full range of values that each of the OSes use but don't do any lossy conversions until we deal with `Duration`, and we can still deal with everything in a cross-platform manner. It does unfortunately result in `MonoTime` holding two `ulong`s instead of one like before, but that's basically what we'd be stuck with on Posix systems if we were using the OS' representation.

> _less_ time. You throw away 2 bits of data on the nanosecond field, since you only need up to 1 billion, and 30 bits is enough for that. Plus, since nanoseconds is your tick, you have less range than if you use hnsecs like we have (and Windows has).

But `timespec` has a `time_t` and a `long` (both of which are 64 bits or 64-bit systems). So, you get a full 64 bits for the seconds and and then 64 bits for the remainder, whereas using 64 bits for all of the ticks would then not only have to share the 64 bits for the full value and the remainder but the full value would have to be in ticks rather than seconds, so it would be much larger, meaning that you couldn't get anywhere near as large a number. And even on a 32-bit system, the fact that the seconds are kept as seconds rather than as ticks means that it can hold a much larger value than even a 64-bit value could hold as ticks. So, as far as I can tell, having

    ulong _seconds;
    ulong _ticks;

is able to hold _much_ larger values than

    ulong _ticks;

ever could have. Most of that range is wasted on most of the OSes, but if Linux and FreeBSD actually use a `timespec` internally (rather than actually holding it as ticks in a `ulong` or something similar), then splitting it like that is pretty much required to hold the full range that they can hold.

> Another possibility is to change ticks to the function osTime, and return the OS representation. This will make it automatically non-cross platform and break code that depends on cross-platform ability (in a good way).

I've thought about that, and we may very well end up doing that, but if I can make this cross-platform in a clean way, then I'd very much like to do so.