Update cache check

[linglingye001]

Why this PR?

Problem

The IFeatureDefinitionProviderCacheable interface in IFeatureDefinitionProviderCacheable.cs is internal, which prevents anyone implementing a custom IFeatureDefinitionProvider from opting into the filter parameter binding cache — a performance optimization that avoids expensive IConfiguration.Get<T>() calls on every evaluation. #367

How the Caching Works Today

if (!(_featureDefinitionProvider is IFeatureDefinitionProviderCacheable) || Cache == null)

If the provider does not implement the internal marker interface, filter parameter binding (the binder.BindParameters(context.Parameters) call) runs on every evaluation — no caching. The ConfigurationWrapper class enables cache invalidation by creating a new reference when configuration changes, so cacheItem.Parameters != context.Parameters detects staleness.

Visible Changes

Update the cache check in FeatureManager to also recognize ConfigurationWrapper-based parameters, so wrappers around ConfigurationFeatureDefinitionProvider automatically get caching without any API changes. For fully custom providers, PR #589 is being worked on to let providers supply FeatureDefinition objects directly (bypassing the configuration layer entirely), which would make the caching question moot.