Proposal: Container and Engine telemetry

This is proposing to add per container metrics, based on cgroups, as well as docker engine metrics about Docker's internal health and job management.

This will either solve or at least provide a basis to address #8875, #1091, #4530, #5473, #8842

# Why?
Tools like cAdvisor talk to the docker daemon as well as access the cgroup kernel features to read metrics from. Even though both use libcontainer, it's error prone and racy. Metrics are coupled to the container and since this container is managed by Docker, it should also provide the metrics for it.

Beside that, metrics are key for every production deployment of Docker. So this is a problem that everyone needs to solve. This is also reflected in the high number of issues asking for native docker metrics.

This also proposes white box telemetry. The idea is to expose various metrics about the Docker internals. For now, some failure/success counters and latencies for the internal job management as well as latencies for the API endpoints.

With the proposed change, it's easy to pull the metrics from Docker into any monitoring system. For smaller setups and on the fly debugging, there will be a metrics endpoint.



# How?
The exposed metrics are pretty raw: We won't do rate conversions or advanced features like histograms and leave this to the monitoring tool. This has the limitation that `docker metrics [container]` will only show the current raw, values. If `-f` is used, it will convert the values into a rate where appropriate. To make it explicit whether a metric is a gauge or a counter, the type is included in the API.
The API is self-explanatory by including a description for each metric.

/cc @aluzzardi @crosbymichael @johncosta @kencochrane 

The kernel, today, typically uses int64max for those types of values.