Add per-item access count stats (blocking and non-blocking)

[fsdvh]

Expose per-item access statistics behind the existing stats feature.

What

• Adds a public ItemStats struct (currently exposing access_count) returned by a new item_stats method on the sync Cache, the unsync::Cache, and the internal CacheShard.
• Adds a non-blocking try_item_stats on the sync Cache: it returns Ok(Some(stats)) / Ok(None) like item_stats, or Err(LockContention) if the shard lock could not be acquired without blocking — matching the other try_* methods.
• access_count tracks how many times an item has been read (get/get_mut/get_value_or_guard/entry) since it became resident. Unlike the internal referenced eviction counter, it is monotonic per residency and not bounded by the eviction policy. It resets to zero when the slot is reused for a new value.
• Both item_stats and try_item_stats behave like a peek: they do not affect the item's hotness or its access count, and return None when the key is not resident.

Notes

• All new fields, methods, and the ItemStats type are gated behind #[cfg(feature = "stats")], so default builds are unaffected.
• The per-item access_count adds an AtomicU64 to each Resident, so the entry_overhead size test is only asserted when the stats feature is disabled.

[arthurprs]

Good addition, thank you. I was almost considering removing the stats feature etc.., but this adds more value to it.

I may add a short commit to the PR before merging later this week.

[fsdvh]

Good addition, thank you. I was almost considering removing the stats feature etc.., but this adds more value to it.

I may add a short commit to the PR before merging later this week.

Thank you for your feedback. We're building a solution on top of quick-cache that introduces persistence, and having such per-item stats would be beneficial for decision-making during content prioritization.