…IT, MISS, STALE_HIT, STALE_REFRESH

…FusionCache into appmetrics

# Conflicts:
#	src/ZiggyCreatures.FusionCache/FusionCache.cs

…s. One uses App.Metrics libarary and the other is .NET Core EventSource/EventCounter implementation. Of course the providers should be pushed to there own repos and nuget packages.

Be warned I locally I packed them and consumed them as nuget packages.  But looks like it works well.  I experimented with the FusionCache.AppMetrics package in a project.  But still need to try the FusionCache.EventCounters in a project with multiple caches.  Not sure if what I did will be friendly to multiple caches yet.  But the bench marks for FusionCache.EventCounters is better than FusionCache.AppMetrics.

… in the ZiggyCreatures.Fusion.EventCounters. More work to do on validation but both AppMetrics and EventSource are usable.

Wiring in Item_Count.  Work still in progress.

…to increment and decrement for various events hasn't worked yet. It also made me question if it was the right way to do it. I think if the cache implements Count then that is the way to poll a current count. With the FusionCache.EventCounter I am committing some experimental work.

Friction Points:
  - IMemoryCache does not have a Count property.  I  have to Inject my own MemoryCache.
  - AddFusionCache extension method does not have a IMemoryCache parameter.  Not a big deal
  - Some usage pattern I have in a project involve some undesirable singletons that store IFusionMetrics and now I would have to take on the IMemoryCache also.  Kind of stuck with this pattern for a while.  Modernizing takes time :(.

The experiment results in accurate counts.  Still need to unwire the old way of tracking but this all brings me to a change to the way I inject IFusionMetrics.

My provider pattern of passing IFusionMetrics would be better implemented with a Plugin that is loaded based on assembly scanning at startup.  Then IFusionMetrics and IFusionCache wouldn’t both have to be passed an IMemoryCache.  The FusionCache implementation would give IFusionMetrics the IMemoryCache.   The implementation of IFusionMetrics would code for the existence of a Count property implementation.

…in FusionCache constructor. Need name to name metrics when a project has multiple caches that I want to measure via metrics. Maybe a first class cacheName property on FusionCacheOptions would be a better way to go?

This plugin technique made my consumption side much easier when using the FusionCache.EventCounter Plugin.

…FusionCache into appmetrics

# Conflicts:
#	src/ZiggyCreatures.FusionCache/FusionCache.cs
#	src/ZiggyCreatures.FusionCache/ZiggyCreatures.FusionCache.csproj
#	src/ZiggyCreatures.FusionCache/ZiggyCreatures.FusionCache.xml

…ainst it.

EventCounter plugin must provide a MemoryCache if a user wants ITEM_COUNT counters.
Core unit tests added for metrics that match all the SingleLevelTests tests.  This was good as I found a few places to change where measurements are triggered.
Added two new benchmark tests: one for AppMetrics plugin and one for EventCounters plugin.

Of course, we need to extract the plugins and probably associated benchmark project out into their own GitHub projects.

…etrics_with_plugins branch. For now.

Just trying to get this back to a clean PR state independent of external dependencies.