[EventCounters] fix deadlock

[Yun-Ting]

Mitigates #1024.

Changes

Below is an example of when the deadlock can occur:

	Thread 1	Thread 2	locks acquired at this timestamp
Time ↓	call ctor of EventCountersMetrics
	lock preInitEventSources		lock on preInitEventSources object by thread 1
	iterate through the HashSet of EventSources AND enable them		lock on EventSource by thread 1
		EventSourceA got enabled by thread 1
		OnEventWritten callback fired on receiving an event
		EventCountersInstrumentationEventSource got lazy-init	lock on EventSource by thread 2
		OnEventSourceCreated callback fired
		lock preInitEventSouces	lock on preInitEventSouces by thread 2

Discussion

1. Better way to mitigate this issue could be, use an assistive dictionary to keep track of whether a particular eventSource should be enabled in a lock, and a flag (for example, shouldEnable) before releasing the lock. Outside of the lock, when the flag was set to true earlier, enable that eventSource. This approach should be more performant as compared to the current implementation. For example: https://github.com/dotnet/runtime/blob/84fd85932fd3b371cad69cc2412404ea50158c63/src/libraries/Common/tests/System/Diagnostics/Tracing/TestEventListener.cs#L84C1-L93C14
2. The locks on preInitEventSources were added in this PR to address the issue -
   "As OnEventSourceCreated can run before the constructor is done, you can run into a situation where you fail to enable an EventSource instance."
   @MihaZupan: Instead of the current locking mechanism, Is it possible in OnEventSourceCreated, we use Spinlock to wait until this.options was set to ensure that OnEventSourceCreated will be triggered only after the ctor got executed? Too hacky?

For significant contributions please make sure you have completed the following items:

• Appropriate CHANGELOG.md updated for non-trivial changes
• Design discussion issue #
• Changes in public API reviewed

[besseb05]

lgtm - although I am not familiar with the codebase

[reyang]

LGTM with a changelog entry.