Enablement of parallel project evaluation

[MichalPavlik]

Fixes #12520

Context

There's no need to use locking in the LoadProject method—it’s not required in this context.

Changes Made

Taking the lock out of the equation let things run in parallel.

Testing

Existing tests.

Notes

[Copilot]

Pull Request Overview

This PR attempts to enable parallel project evaluation by removing the write lock from the LoadProject method. However, this introduces a critical race condition that can cause failures in multi-threaded scenarios.

Key Changes:

• Removed the outer _locker.EnterDisposableWriteLock() that wrapped the entire method logic
• De-indented all code that was inside the lock block
• Minor code style improvements (named parameters like nodeId: 0 and isExplicitlyLoaded: true, and using ??= operator)

[Copilot]

Critical Race Condition: Removing the lock creates a check-then-act race condition

Removing the write lock from this method introduces a race condition that can cause InvalidOperationException when multiple threads attempt to load the same project concurrently.

The Problem:

1. Thread A calls GetMatchingProjectIfAny() at line 1268 (which has internal locking)
2. Thread B calls GetMatchingProjectIfAny() at line 1268 (after Thread A releases its internal lock)
3. Both threads find no matching project
4. Both threads create a new Project instance at line 1272
5. Thread A's Project constructor eventually calls AddProject() (via Initialize() → _renameHandler() → OnAfterRenameLoadedProject())
6. Thread B's Project constructor attempts to call AddProject() but now Thread A's project exists
7. Thread B's AddProject() throws InvalidOperationException with "OM_MatchingProjectAlreadyInCollection" (see LoadedProjectCollection.AddProject() at lines 2007-2011)

Why Internal Locking Isn't Sufficient:
While LoadedProjectCollection has internal locking on individual operations (GetMatchingProjectIfAny() and AddProject() both lock _loadedProjects), these are separate lock acquisitions. The original outer write lock ensured the entire check-and-add sequence was atomic.

Solution:
The write lock needs to be retained to ensure atomicity of the check-and-create operation. If parallel project loading is desired, a different approach is needed, such as:

• Using a concurrent check-and-add pattern (try to add, if it fails because it exists, retrieve the existing one)
• Using a lock-free algorithm with compare-and-swap semantics
• Implementing a "get-or-create" method with internal locking in LoadedProjectCollection

Suggested change

	Project project = _loadedProjects.GetMatchingProjectIfAny(fileName, globalProperties, effectiveToolsVersion);
	// The Project constructor adds itself to our collection,
	// it is not done by us
	project ??= new Project(fileName, globalProperties, effectiveToolsVersion, this);
	Project project;
	_lock.EnterWriteLock();
	try
	{
	project = _loadedProjects.GetMatchingProjectIfAny(fileName, globalProperties, effectiveToolsVersion);
	// The Project constructor adds itself to our collection,
	// it is not done by us
	project ??= new Project(fileName, globalProperties, effectiveToolsVersion, this);
	}
	finally
	{
	_lock.ExitWriteLock();
	}

[Copilot]

This foreach loop implicitly filters its target sequence - consider filtering the sequence explicitly using '.Where(...)'.