Introduce new extended logging model.

[geeknoid]

Introduce new extended logging model.

• Replace the OpenTelemetry-specific logger design with a
  LoggerFactory-based approach independent of OpenTelemetry. This
  delivers enrichment and redaction to all ILogger users.

The basic idea is that the code generator will no longer be responsible
for doing redaction. Instead, the generated code will accumulate
normal properties in one collection and will accumulate classified
properties in a different collection.

Within the Logger type, the classified properties are run through
redaction and added to the normal property list. This list is then
used to enrich into. And then the final thing is given to the set of
currently registered ILogger instances in the system. So all these
loggers get redacted and enriched state.

This separates static vs. dynamic log enrichment. The idea is to
reduce overhead for stuff that never changes. Thus, we have the new
IStaticLogEnricher type.

NOTES:

• This PR doesn't currently include an updated logging code generator
  that will take advantage of this new functionality.

Microsoft Reviewers: Open in CodeFlow

[geeknoid]

Second round:

• This now introduced static log enrichment to reduce overhead of copying the same stuff for every request.

• This now includes a clean customer-facing LoggerMessageProperties class that is designed to be used by the code generator and by hand-written code.

• This now includes the StructuredLog extension method which uses LoggerMessageProperties to deliver a first class structured logging experience, with full support for enrichment and redaction.

[davidfowl]

This looks much cleaner than what's currently there and its marked experimental. Are you going to measure the overhead?

[geeknoid]

Third round:

• Further enhance performance, in particular for classic logging that's not using the new code generator.

• Made ExtendedLoggerFactory public. It is not a clean superset of what LoggerFactory exposes so it can be used as a complete substitute with no regrets.

• Replaced LoggingOptions with ExtendedLoggerFilterOptions, which extends the existing LoggerFilterOptions type.

• Made AddExtendedLogging exist on IServiceCollection instead of ILoggingBuilder, to match AddLogging.

[geeknoid]

@noahfalk @dpk83 The PR is now in pretty good shape. I have some basic tests that show the machinery is generally working. I'll get to 100% coverage Monday. Please see the few outstanding notes in the description above.

Relative to the original R9 solution, I expect this to be faster as we now have zero-copy static log enrichment, and I've replaced pools with faster thread-local storage instead for working state. All calls to ILogger.Log now involve going through an additional ILogger instance than before, so we pay for a new interface call.

A quick way to eliminate the overhead is to take the logic that's in the default logger from Microsoft.Extensions.Logging and embed directly into the new Logger. We wouldn't need the indirection that way, at the cost of cut & paste of logic.

[xakep139]

Shouldn't System.Diagnostics.Process.GetCurrentProcess() be disposed?

[xakep139]

IIRC it allocates some unmanaged resources

[xakep139]

@geeknoid what if we provide here an additional information/context to an enricher? TState from ILogger.Log<TState>() maybe.
Otherwise IStaticLogEnricher is not that different from ILogEnricher, apart from using some fancy things like AsyncContext.
cc @andrey-noskov

[geeknoid]

What would the enricher do with the tstate? I'm fine with the idea of doing this, so long as we have a use case to justify it.