Add registry for external sinks

[banks]

Fixes #63

Comments welcome. I added registration to existing sub-package sinks. Happy to leave that out if there is a good reason to not auto-register those. I added some basic tests for those but have not actually tested end-to-end.

[blalor]

This looks good!

go test fails because of the issue addressed in #88; I cherry-picked that PR into this branch and tests pass.

[blalor]

Upon further investigation, all of the sinks need to be registered; right now that only happens if the sink's package is imported in another program. Without that, metrics.NewMetricSinkFromURL("dogstatsd://localhost:8125") will return an error.

[banks]

@blalor that was the intention - if we default imported all the packages to avoid that then there is not much use having them as separate "optional" packages since they would always be pulled in even if not used, and would be enabled for any aoplication that uses this even if not desired just because the end-user could modify the URL.

Requiring the extended (or any other third-party) sink to be explicitly enabled via an anonymous import make this a backward compatible change (no new features or code magically enabled for existing applications), while allowing both the extended sinks in the repo and external ones to re-use the same setup/config via url.

[banks]

I agree we should maybe document that the anonymous import is needed in the comments added here and probably in the README though...