Add new service to use instrumentation classes

What does this MR do and why?

With this MR we add a new service to take care of generating the service ping payload.

How to set up and validate locally

When having feature enabled merge_service_ping_instrumented_metrics

counts.boards metric should be present when using the service Gitlab::Usage::ServicePingReport.for and it should not be present when using the UsageData classes

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values) 
# Should not counts boards key
Gitlab::UsageData.data

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: : metrics_queries)
# Should not have  counts boards key
Gitlab::UsageData.UsageDataQueries

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: : non_sql_metrics_values)
# Should not have  counts boards key
Gitlab::UsageDataNonSqlMetrics.data

When having feature disabled merge_service_ping_instrumented_metrics

counts.boards metric should be present in both cases

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: :all_metrics_values)
# Should have counts boards key
Gitlab::UsageData.data

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: : metrics_queries)
# Should have counts boards key
Gitlab::UsageData.UsageDataQueries

# Should have counts boards key
Gitlab::Usage::ServicePingReport.for(output: : non_sql_metrics_values)
# Should have counts boards key
Gitlab::UsageDataNonSqlMetrics.data

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #346640 (closed)