Caches: remove EntityPool, improve metrics, add eviction stress test

[majocha]

Edit:

First of all, this fixes #18819 by removing EntityPool from Cache.
The problem manifested itself when executing EmittedIL.Structure tests in parallel.
It was reproducible locally. I checked locally that it's fixed by running many iterations ("run until failure" in VS) without fail.

Some additional checks and tests around eviction added around a singular possible eviction fail I noticed in the CI:

Data collector 'Blame' message: The specified inactivity time of 5 minutes has elapsed. Collecting hang dumps from testhost and its child processes.
Data collector 'Blame' message: Dumping 29900 - testhost.net472.
Results File: D:\a\_work\1\s\artifacts\TestResults\Release\FSharp.Compiler.ComponentTests_NETFramework472_batch2.xml
Test Run Aborted.
The active Test Run was aborted because the host process exited unexpectedly. Please inspect the call stack above, if available, to get more information about where the exception originated from.

The test running when the crash occurred: 
Passed!  - Failed:     0, Passed:   427, Skipped:    17, Total:   444, Duration: 3 m 19 s - FSharp.Compiler.ComponentTests.dll (net472)
Miscellaneous.FsharpSuiteMigrated_CoreTests.lift-FSI

Miscellaneous.FsharpSuiteMigrated_CoreTests.test int32-FSI
CompilerService.Caches.Eviction of least recently used
Language.NullableCSharpImport.TypeBuilder CreateTypeInfo with an upcast

This could mean that the test that waits for eviction event never gets that event in some rare circumstances.
So, this adds another diagnostic event EvictionFail. If it ever happens (again?), it should show up in CI.

A basic stress test is added. I also cleaned up CacheMetrics code a bit.

Another thing: depending on the dotnet test's --blame-hang-timeout instead of using explicit timeouts in the tests. This sounds good in theory. In practice, if the testhost timeouts while executing tests in parallel, the only info we get is a bunch of tests that were executing at the moment. A pragmatic solution would probably be:

#if DEBUG
let shouldNeverTimeout = 15_000
#else
// accomodate unpredictable CI thread scheduling
let shouldNeverTimeout = 200_000
#endif

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md	No release notes found or release notes format is not correct
vsintegration/src	docs/release-notes/.VisualStudio/18.0.md	No release notes found or release notes format is not correct

[majocha]

That's weird, Delegates01_fs(compilation: File: Delegates01.fs) on MacOS:

[T-Gro]

Thanks @majocha for finding the mistake which caused tests randomly to fail!

The race was within the pool usage?

[majocha]

The race was within the pool usage?

Yes, see #18819 (comment)

I tried disabling the pool and it fixed things. Then went through the file with copilot, some diagnosis was misguided but it did catch it and explain what's going on.