Performance Area: ETW Logging of DateTime

#### Overview

This is a small one, but with aspects of ETW I'm not aware of in terms of transitioning. In the IEventGenerator for ETW, every log line flowing through here ([from ``SystemLogger`](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.WebHost/Diagnostics/SystemLogger.cs#L159)) is efficiently handled [down to a stack-allocated `EventData`](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.WebHost/Diagnostics/ExtendedEventSource.cs#L28-L42).

It's a very efficient pipe except for one allocation we repeat a lot: [converting the date into a string](https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script.WebHost/Diagnostics/EtwEventGenerator.cs#L27) once per event. In a Hello World scenario this is about 6.5% of our overall allocations in current `dev` branch (and growing, as we eliminate other allocations):

#### Proposal
ETW is designed around this to accept the `DateTime` as a `long` ([using `DateTime.ToFileTimeUtc()`](https://docs.microsoft.com/en-us/dotnet/api/system.datetime.tofiletimeutc?view=net-6.0)) - can we use this down through `EventData` creation? [This is what the built-in converter does](https://github.com/dotnet/runtime/blob/6482d14e4dd1cdb04f10ccd15e3df95f684d5aa5/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventProvider.cs#L897-L909).

I'm not familiar enough with ETW -> Kusto to reason about the pipeline and what the consequences of _changing_ to the efficient version are, or if there are tradeoffs. I'm not sure if we can change the `string` entries to `long` directly and it just work or this is an impactful schema change.

Writing this up as a performance impact area, hoping someone more familiar with ETW can chime in on if/how we can change this (or we accept this cost and move along).

cc @AnatoliB @RohitRanjanMS @gzuber

Start in src/WebJobs.Script.WebHost/Diagnostics/EtwEventGenerator.cs and trace the event path through SystemLogger.cs and ExtendedEventSource.cs. Compare the current DateTime string conversion with the referenced EventProvider converter, then determine whether passing a long changes the ETW-to-Kusto schema or behavior. Done means documenting or implementing a validated approach with its compatibility consequences.

Written by the indexing model from the issue text.