Added support for non-default Prometheus CollectorRegistry

[llucherini]

Hey.
This PR introduces a new constructor in PrometheusMetricsTracker and a constructor overload in PrometheusMetricsTrackerFactory to enable configuration of whatever Promethes CollectorRegistry one might want to use. It's completely backwards compatible and shouldn't affect any existing codebase relying on this.

[coveralls]

Coverage increased (+0.06%) to 77.228% when pulling 02a2d4a on llucherini:dev into 3b8d964 on brettwooldridge:dev.

[cemo]

Hi @llucherini,

What was your use case to adding custom registration support? Since this current buggy form does not support multiple datasource and causing errors we need to fix this. However custom registration makes the code pretty much ugly to fix.

[cemo]

Please see #851

[cemo]

BTW It is worth to mention CollectorRegistry from Prometheus javadoc:

The majority of users should use the {@link #defaultRegistry}, rather than instantiating their own.
Creating a registry other than the default is primarily useful for unittests, or pushing a subset of metrics to the Pushgateway from batch jobs.

So I offer to revert this change which is causing ugly implementations to fix current buggy implementation.

[llucherini]

Hey. The use case is exactly the one stated in Prometheus javadocs, unit testing.
For us this is a nice to have, but it's not extremely important or vital, so feel free to revert it.

[cemo]

thanks @llucherini.

We will revert this change in favor or supporting multiple datasource at once.