ConcurrentDictionary.Count bypass

[SimaTian]

profiler was repeatedly complaining about ConcurrentDictionary.Count taking locks too often.
This PR introduces an approximate counter to remedy that

Context

ConcurrentDictionary.Count locks all its internal locks to have the count accurate and up to date.
However we only use the count to check if there is a reason to clean up the cache - e.g. we should be fine with a variable that is almost-in-sync with the .Count, that we can update atomically and then read without locking.
The increment is atomic, the read is accurate enough and the "flush cache" section is already behind a lock.

Changes Made

Introduced _count variable that lists the same value as ConcurrentDictionary.Count would.

Testing

Now that I looked at this, we didn't have a test for the scavenge threshold. We only ever tested the .scavenge directly.
Do we want to remedy that or are we fine as is?

[JanKrivanek]

Thanks!