Console formatter improvements for developers (#6391)

[sgryphon]

Fixes #6391
Design discussion issue #none

Changes

• Adds multiple formatters to the console exporter
• Legacy verbose key value formatter is retained
• New developer-focused simple formatter added
• Simple formatter:
  • Compact format, written in a single line
  • Coloured, to easily identify log levels
  • Suitable for an application developer to use for local app dev, running in a console, as a replacement for the Microsoft Console logger provider.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

NOTE: There is minimal changes to the public API, just adding a small number of configuration options.
Most code is internal, allowing easy future improvement.

Notes

This was originally a Contrib submission, as a completely separate exporter, but it was requested
to change to be an update to the default console logger.

This is not meant to address every console logger requirement, but has a specific focus on something
application development friendly. It is not meant for production performance, or to be flexible, or output
to files.

It is meant to be something that an application developer can use during application development, running
in a local console. The output format is compact (2 lines), uses colour, and much less verbose than the previous
default console logger.

Other considerations (e.g. performance) are no worse than the existing KeyValue formatter; only the formatting
has been improved (simplified).

I have kept the previous logger as an alternative 'KeyValue' formatter, in case anyone wants that format
(it is a lot more verbose), but for details of the full attributes of any telemetry a developer could
also use an appropriate local tool, such as Loki (for logs) or Jaeger (for traces), etc.

Output format bikeshedding

The format used for the output could be debated ad-infinitum. Rather than spend time on this,
I'd like to get a basic console logger in with any reasonable format.

If the senior project lead on OpenTelemetry .NET (a project should not be a democracy) has a specific format /
change to the format, I'm happy to make it to get things merged.

What I don't want is a half dozen people suggesting different minor tweaks as you could forever be debating
colours, abbreviations, order of the attributes, etc.

The longer term plans are to have a customisable format anyway, so the sooner we get this in, the sooner
someone can start on that.

The chosen format

Originally my Contrib submission was very similar to the default .NET Console Logger, so it could operate
as mostly a drop in replacement with no visible difference to the user except that it would include
Trace ID when available.

This version leans more towards OpenTelemetry standards.

• It uses OpenTelemetry standard Severity (Range) Names (instead of .NET names)
• Colours are taken from .NET console log.
• Includes the EventName (instead of ID). This is automatically set if using the recommended source-generator LoggerMessage high performance pattern, so works out quite well.
• Includes the TraceId and SpanId.
• Defaults the timestamp to on with HH:mm:ss, because a local run you usually know the date and just want to know how recently events happened.
• Actities (Spans) are output with their end timestamp (so the timestamp is in order), and duration in ms.
• Metrics are similarly output with their end time, and the period they cover in seconds, along with tags and values.

Resource details are not output by default, as usually you are running one application in the console on your local machine.

The main thing missing from .NET logs is the CategoryName, which doesn't have a direct equivalent in OpenTelemetry. The indentation is also different, to align with the default timestamp (rather than severity), and output is written in a single line (rather than 2).