Distributed Cache Improvements

• Use distributed locking for GetOrAdd... methods. Currently, we are using in-process locking, which is fine, but doesn't prevent multiple write operations. That means if the data is read from database, multiple processes unnecessarily read it multiple times. This can be a good optimization. This should be optional and per cache, because it has a cost. We can add an attribute to cacheitem class, like [UseDistributedLock] to indicate it.
• Implement in-memory cache layer. This would be good for rarely changing big data. I've implemented a similar thing manually for dynamic permissions (DynamicPermissionDefinitionStore and DynamicPermissionDefinitionStoreInMemoryCache classes can be checked). This covers https://github.com/abpframework/abp/issues/3854 too. Note that we should enable this only for real distributed caches, not for the default memory cache - it is already in-memory. This should be optional and per cache, because it has a cost and not necessary for all objects. We can add an attribute to cacheitem class, like [UseInMemoryCacheLayer] to indicate it. We can also benefit from cache server's (e.g. Redis) events to get notified when the cached item has changed (updated/deleted) if the server supports.

Start by reviewing the cache GetOrAdd methods and the DynamicPermissionDefinitionStore and DynamicPermissionDefinitionStoreInMemoryCache classes referenced in the issue. Compare the existing in-process locking and default memory-cache behavior before defining the per-cache options and invalidation approach. Done means both distributed locking and the optional in-memory layer work without changing default memory-cache semantics, with coverage for supported cache implementations.