Replace OpenTelemetry with armon/go-metrics

## Summary
After a few months of weighing the current state of OpenTel vs the current need for metrics wrt to the Consul ecosystem, it has become more evident to me that switching to [`armon/go-metrics`](https://github.com/armon/go-metrics) would provide the most cohesive and comprehensive feature set at this time.

### Background
PR https://github.com/hashicorp/consul-template/pull/1378 recently introduced metrics to Consul Template using OpenTelemetry. There's a short blurb providing context as to why OpenTel was initially chosen over `armon/go-metrics` and that it was an experiment towards a new library for telemetry.

### Context
I tried to create a uniform UX for configuring and emitting metrics over on [Consul ESM #70](https://github.com/hashicorp/consul-esm/pull/70), another Consul ecosystem project, and quickly ran into some short comings when dealing with more complex metric types than counters and histograms. For example, timer values were reduced to histogram integers, and there currently is not a systematic way to denote measurement (seconds, milliseconds, etc).

The community request for `statsd` is not quite satisfied yet due to the difference in tag syntax between statsd variants and would require omitting the use of tags as a whole to continue support for statsd.

### UX
The metrics reported should not change much from the initial work in https://github.com/hashicorp/consul-template/pull/1378 (not yet released). However, the telemetry configuration will be breaking changes compared to the PR and align closer to how it is supported by Consul ([docs](https://www.consul.io/docs/agent/options#telemetry)).

Switching libraries will add feature support for:
* statsd, circonus
* more metric types, like timers and gauges
* tags and global tags
* metrics prefix
* prefix filtering

Start by reviewing PR 1378 and the Consul telemetry documentation referenced in the issue, then compare the current OpenTelemetry integration with armon/go-metrics. The work is done when metrics behavior remains consistent while the requested metric types, tags, prefixes, filtering, statsd, and circonus support are covered by the new configuration and implementation.

Written by the indexing model from the issue text.