Consider reducing ETW events

During investigation of graph build I have find out that we might be tracing too many ETW events.

I believe that amount of ETW tracing shall be reasonable as extensive ETW logging can cause:
- too big overhead of capturing ETW events, which could skew perf traces
- too big trace files slowing down investigation
- way too big trace files causing perfview capture circular buffer overrun which results in missing events - prohibiting some trace analysis
- all above will result into more difficult/impossible trace capturing of tools integrated with MSBuild - such as Visual Studio

Event Statistics

NameCountAverage
Data SizeStack
CountMicrosoft-Windows-Kernel-File/Create4,292,9402734,292,940Microsoft-Build/ApplyLazyItemOperations/Stop3,170,927320Microsoft-Build/ApplyLazyItemOperations/Start3,170,924320Windows Kernel/StackWalk/StackKeyKernel2,466,245240Windows Kernel/StackWalk/StackKeyUser1,841,718240Windows Kernel/TcpIp/TCPCopy1,809,001280Windows Kernel/PerfInfo/Sample1,383,667161,365,310Windows Kernel/StackWalk/KeyDelete1,345,3362990Microsoft-Windows-DotNETRuntime/ClrStack/Walk1,090,2824460Windows Kernel/DiskIO/ReadInit784,79912784,799Windows Kernel/DiskIO/Read784,799520Microsoft-Windows-DotNETRuntime/ThreadPoolWorkerThread/Wait776,601100Windows Kernel/TcpIp/Recv776,115281Windows Kernel/DiskIO/WriteInit689,64812689,648Windows Kernel/DiskIO/Write689,647520Microsoft-Windows-DotNETRuntime/GC/AllocationTick644,655168644,639Microsoft-Build/EvaluateCondition/Stop608,0351320Microsoft-Build/EvaluateCondition/Start608,0341280System.Diagnostics.Eventing.FrameworkEventSource/ThreadPoolEnqueueWork481,6858481,685

Based on above we shall reconsider if we need `ApplyLazyItemOperations(Start|Stop)` and `EvaluateCondition(Start|Stop)`.

Easiest solution would be to have them `#IF DEBUG`.

Note: In case it is needed to capture at customer equivalent data are captured by [Evaluation Profiling](https://github.com/dotnet/msbuild/blob/main/documentation/evaluation-profiling.md)