Logary v2.0 with HealthChecks service, better metrics, Riemann, Elmah.io, Logentries, Loggr targets, SQL Server health, Topshelf integration

This PR is work towards the vision that a log/metric framework is about ensuring software invariants and providing visibility into the software.

First of all, as the README now states, I'm trying to make it explicit in the code where calculation is taking place, separating that from pure data capture.

Secondly, a lot of data capture of data that's already processed (averages, quantiles, rates etc) is really about verifying you service's invariants, not about monitoring *your code*, so that's what's called `HealthChecks`.

Thirdly, there are two ways of capturing invariants for services; one as a single-purpose monitoring solution that is extensible in code in what data it captures, or alternatively running monitors inside of your service that continuously poll or check those invariants.

As a developer you often construct a mental picture of how you want your software to be configured. E.g. if you're fortunate to work with public IPv4s you might get an idea to identify each of your services as IP+Host-header-binding and locate with DNS A-pointers. Now you have introduced a system-wide invariant, because the system administrators that manage your DNS have no idea about how you app uses it -- and therefore can never change it without talking to you -- with Logary you can now instead place a system-global HealthCheck that describes the reason for the DNS entry and continuously verifies the invariant in unbroken, alerting you if it breaks.

This sort of functionality is great to have when there's been four years since some dev wrote some service and you have no documentation about it; running code that is self-describing wins over organisational memory any day of the week.

The same goes for non-system-wide invariants, arguably the most common kind, where you have a dependency on a resource/service from your service. Simply add a HealthCheck for that service and you can use Riemann to notify you of any problems in the production environment of your service. Similarly, when you no longer need your code and want to decommission the service, just shut it down and the invariant check/monitor is gone.

### Breaking:

 * `module Measure` takes over what `Metric` did before, is about constructing a `measure` instance.
 * `Measure` -> `measure`
 * Remove `MetricType` as it doesn't make much sense
 * `module Metric` removed/refactored into what it *means*
 * `module Log` -> `module LogLine` - use to construct log lines that you want to log
 * `LogLine` -> `logline`
 * Removing a bunch of `GetXXX`-functions from the registry in an attempt to clarify how to calculate metrics, instead of just opening up lots of options that take the developer mental bandwidth to understand
 * `Logger` -> `logger` with `module Log` being split into `module Logger` and `module LogLine` for its respective concerns
 * `HealthCheck` -> `healthcheck` and more code in `module HealthCheck` to make it easier to work with it

### Adding features

 * Creating a proper .Net/mono riemann client, because we're worth it.
 * Adding functions to compose health checks in the `HealthChecks` module
 * Integrating health checks with the Registry and removing second-order events/metrics from its public API
 * Infrastructure.fs contains a `Lenses` module for interacting with `LogLine` and `Measure` on a higher level

### More writing

 - See the README.md
 - [Comparison](https://gist.github.com/haf/5e770676d8c007ca80c1) with [exometer](https://github.com/Feuerlabs/exometer).