Document (with example) how EnrichmentProcessor must be authored without sacrificing performance in Log pipeline

[Cijo Thomas]

We recently tweaked Logger.IsEnabled() capabilities to allow filtering decisions to be made based on name/scope(target),level.
This can greatly improve performance when us OS-native exporting (etw/user-events), as it allow us to determine that a particular Log is un-interesting, and can be skipped.

However, if a EnrichmentProcessor was also added, it will by default return true for the Enabled() check, forcing the Logger to anyway create the LogRecord, have it enriched by the EnrichmentProcessor, and then given to exporting processor, only to get it dropped there. To make this work without losing performance, the EnrichmentProcessor must wrap the exporting processor, and delegate calls to Enabled() to the underlying one.

Opening an issue to show an example on how to do this.

(Note: For users who want utmost performance, it can be argued that the enrichment can be done out-of-process, but sometimes, it is not feasible, if Context information is required.)