[vs17.12] Fixing the contention condition caused by RegisterResolversManifests

[github-actions]

Fixes #11079

Work item (Internal use):
https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2400156

Summary:
Backport of #11079 to vs17.12
There was a contention condition described #7927 (comment):
One thread enters and locks, then initializes a list, starts pushing things onto the list, which is now no longer null.
Second thread then checks, sees the list is not empty and bypasses the lock, acquires enumerator.
First thread pushes additional item into the list.
Second thread throws.

We want to backport it to 17.12 (which is 9.0.100) so it is a part of the source build.
That means that a large part of our Linux userbase which runs on source builds SDKs is exposed to the problem and they could experience failures at any time - and they won't have the fix unless we backport.

Customer Impact:
It is an annoying error that occasionally kills a multiprocessed pipeline due to a contention condition.
Fortunately it only manifests occassionaly, however it happens often enough to be noticeable. We have at least two well documented cases as of recently and even more if we extend the time window.

Regression:
No, it is a long standing bug.

Testing
src/Build.UnitTests/BackEnd/SdkResolverService_Tests.cs
test to validate the error is no longer there. (See the original ticket for discussion)

Risk
Low, the change is already rolled out and tested in the main branch.

[rainersigwald]

Holding for a later release, removing servicing-consider for now.

[SimaTian]

Since we discussed this yesterday on sync, can we restart the backport please?
cc @rainersigwald @JanProvaznik

[rainersigwald]

@SimaTian please fill out the Tactics template--https://github.com/dotnet/msbuild/blob/main/.github/PULL_REQUEST_TEMPLATE/shiproom.md. Include the motivations we discussed yesterday.