Add SDK Log health metrics

[JonasKunz]

Follow up of #1631 adding SDK health metrics for logs.

Changes

Adds:

• A metric to count the number of logs generated submitted to the SDK (only enabled loggers count)
• Count metrics for LogRecordProcessors and LogRecordExporters to track data loss

The processor and exporter metrics are very similar to the span-ones in #1631. In fact, they are pretty much a copy-paste.
So I think with the concrete examples at hand now, it would be a good time to revisit the decision and reasoning whether to keep the metrics separated per signal or combine them with and differentiate via an attribute (e.g. otel.signal.kind=span,log,metric).

The detailed reasoning for separation can be found in this comment.

I still think that reasoning holds for processors: Log and Span Processors do have the same name, but work differently (e.g. span processor has multiple callbacks). Therefore it makes sense to have different namespaces for their metrics to not make things ugly in the future when new, span or log specific metrics need to be added or the processor specs diverge further. This already shows in the fact that metrics do not have processors, but MetricReaders.

For the exporters I'm not so sure anymore: The exporters are separated in the spec, but it is in fact mostly copy-pasted and I think they are unlikely to diverge. So if we wanted to reduce the size of the spec here and ease some queries (e.g. "are there errors in any exporter?"), we could think of combining them.
In the SIG meeting we decided to keep them separate for now, see #2002.

Looking forward to hearing your opinions here!

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[AlexanderWert]

@open-telemetry/specs-semconv-approvers @open-telemetry/specs-semconv-maintainers
Can we get more reviews on this please?

This PR is a continuation of #1631, now doing it for the Logs signal, but otherwise analogous to #1631.

[lmolkova]

related to #1979

[JonasKunz]

In accordance with #1979, I've adjusted the metric names in bf5cd8d. Based on the names we decide on here for the log metrics, I'll open up a follow-up PR to adjust the span metrics accordingly to remove the .count suffixes.