Proposal: Rework metric instantiation to get-or-set from the registry

At present (v0.19.0 and previously) the prometheus_client.registry.Registry class is secondary in terms of API control flow to the prometheus_client.metrics.MetricWrapperBase and subclasses in that a caller says prometheus_client.Counter() and doing so implicitly first instantiates a new metric and then registers the names it defines into the global registry.

This makes the default behavior of the library code-reloading unsafe. Today if you reload code which invokes Counter(), you get a new counter instance which encounters a name conflict when it tries to register itself.

It would be better if the primary interface first performed a get-or-set against the specified registry so that reloading would re-fetch the original counter functionally as a singleton.

The real solution is that we should be explicitly managing and lifecycling registries, but the library default behavior of using a shared global registry creates this pitfall.

Beginne mit dem Lesen von prometheus_client.registry.Registry und prometheus_client.metrics.MetricWrapperBase, einschließlich der Frage, wie Counter() Namen in der globalen Registry registriert. Verfolge den Namenskonflikt beim Neuladen und definiere das erforderliche Get-or-Set-Verhalten der Registry, damit beim Neuladen die vorhandene Metrik erneut abgerufen wird, ohne eine doppelte Registrierung vorzunehmen.