Improve ANCM file watcher thread management

[adityamandaleeka]

I'm trying to get rid of TerminateThread usage in ANCM and decided to tackle the file watcher thread first. This change includes various improvements to the file watcher thread management and shutdown mechanisms.

• Creation of a new shutdown event m_pShutdownEvent that provides a more explicit and straightforward way to signal the thread to exit.
• Refactoring of FILE_WATCHER::ChangeNotificationThread to use WaitForMultipleObjects to wait on either the completion port or the new shutdown event, removing the need for the FILE_WATCHER_SHUTDOWN_KEY mechanism.
• Simplification of FILE_WATCHER::WaitForMonitor by removing calls to GetExitCodeThread and TerminateThread, relying on WaitForSingleObject to handle thread state checking and waiting.
• Replacement of the volatile BOOL m_fThreadExit with a std::atomic<bool>
• Other minor improvements

Contributes towards #45066

[BrennanConroy]

What happens if the thread doesn't exit after the loop completes?

And, should we log in that case?

[adityamandaleeka]

Good idea, done.

[adityamandaleeka]

One option if we want to de-risk this in .NET 8 is to enable the termination behavior behind a flag.

[BrennanConroy]

What is the thread doing that could be "bad" if it's still running?

[BrennanConroy]

Offline discussion: The thread is holding onto state that can have undefined behavior if accessed when the class is destructed. e.g. FILE_WATCHER* and the m_pShutdownEvent and m_hCompletionPort events.

Which brings up another thing, those events are never closed via CloseHandle it looks like.

[BrennanConroy]

Suggested change

	WaitForSingleObject(m_hChangeNotificationThread, INFINITE);
	LOG_INFO(L"Waiting for File watcher thread to exit.");
	WaitForSingleObject(m_hChangeNotificationThread, INFINITE);

So we know if it's hanging. The thread itself logs when it exits.

[BrennanConroy]

I think a log should be added