Fixes a few problems in metrics

[tjquinno]

Resolves #2239

I found two additional problems in our metrics implementation as I was working on adding MP Metrics 2.3 support, leading to the following groups of changes:

1. Internally, each metric implementation emits its own Prometheus/OpenMetrics output. The invoking code tells those metrics whether to include HELP and TYPE information. HelidonMeter and HelidonConcurrentGauge which have "sub-metrics" did not honor that flag for all their sub-metrics. These changes fix that.

2. Added a getMetricsByName method to Registry which returns a List of MetricID/Metric pairs that match a given name.

3. Changed the MetricsSupport#getOne method, to which /metrics/registryName/metricName requests were routed, to #getByName and changed its implementation to use the new method created in 2 so it fetches and reports on all metrics that match the name, not just one.

Re: # 3, here is how the spec indicates what the output should be:

/metrics//<metric_name> | GET | JSON, OpenMetrics | Returns the metric that matches the metric name for the respective scope
-- | -- | -- | --

It's in the middle of a table describing what the output should be for various paths and it does say "the metric" so it does not seem ambiguous about the case where multiple metrics share the same name. But the 2.3 optional TCK includes at least one test that depends on all metrics matching a name being returned. I am including that change here, rather than in the later PR with all the 2.3 support, to highlight this change. (The 2.2 TCK and all tests and examples passed locally with this change in place.)