logging changes

[brettsam]

A couple of notes about the approach here. I think that we should follow a similar pattern to gRPC: https://docs.microsoft.com/en-us/aspnet/core/grpc/diagnostics?view=aspnetcore-5.0. There's a mix of logging, DiagnosticSource, and metrics where necessary. This only gets us running with the logging part and the others can follow up later.

Also see this great comment about logging abstractions in .NET.: aspnet/Logging#332 (comment). You can check out the entire issue -- lots of good stuff there.

Notably:

1. Context no longer has a Logger parameter.
2. Logger can be accessed via DI. This removes the ILogger param that we've had for WebJobs and in-proc that has caused confusion. ILogger isn't something typically injected by DI (.NET only supports ILogger<T>. It meant that in WebJobs/Functions we had to come up with a logger category that we passed to you -- which led to a bunch of other confusing issues for customers. Now you can access a logger by:
   • Injecting ILogger<T> into constructor
   • Using GetLogger extension method on context, which pulls the logger from the InstanceServices for that execution.
3. Internally, use AsyncLocal to flag logs that are coming from us, so we know they are System logs. Note. I don't currently like this. I've commented in the PR and I'm working on a change to make this a more complete solution. Update: I've now taken care of this with the new WorkerMessage.Define. See note below
4. Adds a logging scope with currently two properties (that we'll document like gRPC does). These provide context for any logging inside of an execution.

[fabiocav]

Should we consider moving this to a partial with <file>.Log.cs like in the host?(https://github.com/Azure/azure-functions-host/blob/13a43aaa7d7f8441a51233083e692cc584f49143/src/WebJobs.Script.WebHost/Middleware/HostAvailabilityCheckMiddleware.Log.cs)