Don't move Properties and Items to ProjectEvaluationFinished if legacy loggers present

[KirillOsenkov]

Fixes #6498

Summary

Switch from the "use the new logic if any logger is present that supports it" to the more conservative "use the old logic if any logger doesn't support the new logic".

Customer impact

Customers who use MSBuild binary logs in conjunction with a legacy logger like one Azure DevOps provides for you would see a crash

MSBUILD : error MSB4017: The build stopped unexpectedly because of an unexpected logger failure. 
Microsoft.Build.Exceptions.InternalLoggerException: The build stopped unexpectedly because of an unexpected logger failure. ---> System.NullReferenceException: Object reference not set to an instance of an object. 
at MSBuild.Logger.BuildConfiguration.Equals(Object obj) 
at System.Collections.Generic.ObjectEqualityComparer`1.Equals(T x, T y) 
at System.Collections.Generic.List`1.Contains(T item) 
at MSBuild.Logger.ProjectTrees.AddTopLevelProject(ProjectStartedEventArgs startedEvent, BuildConfiguration platformConfiguration) 
at MSBuild.Logger.CentralLogger.HandleProjectStarted(Object sender, ProjectStartedEventArgs e) 
at Microsoft.Build.BackEnd.Logging.EventSourceSink.RaiseProjectStartedEvent(Object sender, ProjectStartedEventArgs buildEvent) 

Without this fix, there are two available workarounds:

1. Disable the crashing logger, or
2. Set an MSBuild environment-variable escape flag

Regression?

Yes, #6287 caused 16.10 to regress against 16.9 (and former).

Changes Made

Switch from the "use the new logic if any logger is present that supports it" to the more conservative "use the old logic if any logger doesn't support the new logic". Effectively the new logic will now only take place when the binary logger is the only logger.

Testing

Unit tests, inspection of state in debugger.

Risk

Low. Makes the validate escape-hatch codepath more common.

[KirillOsenkov]

/asp run

[rainersigwald]

Retargeted to 16.10 for servicing; applying Tactics label for servicing consideration.