If this library is imported into an app that already uses prometheus and initializes the client, then the second client init will fail because of re-registering the enum

#### Expected behavior

If client_model/go/metrics.pb.go has already been initialize it should not be done a second time.

#### Actual behavior

Second initialization causes a panic.
panic: proto: duplicate enum registered: io.prometheus.client.MetricType

`goroutine 1 [running]:
github.com/golang/protobuf/proto.RegisterEnum(...)
/local/flogo/2.9/lib/core/src/github.com/golang/protobuf/proto/properties.go:458
github.com/prometheus/client_model/go.init.0()
/tmp/cli-workspace/bs_227664905/engine/src/github.com/prometheus/client_model/go/metrics.pb.go:663 +0x332
`

#### Steps to reproduce

Import the pulsar library into an app that already uses the prometheus client.

#### System configuration
**Pulsar version**: master

I recognize that this may be a problem generic to protocol buffers. I have hacked the client init method to ignore double inits of enums (just like types) and all is fine. This is because the enums are, in this case, the same. In my case both the pulsar client, and the othe package using protocol buffers are not in my code and therefore a little out of my control. I can run with a hacked prometheus client, but that become complicated going forward.

Just looking for thoughts here...
Thanks in advance.
wcn

Start by reproducing the panic when the Pulsar library is imported into an app that already uses Prometheus, then inspect client_model/go/metrics.pb.go and the proto.RegisterEnum call shown in the stack trace. Determine how duplicate initialization occurs and verify that the same integration no longer panics when the reproduction is run.

Written by the indexing model from the issue text.