Product/version: Telerik Reporting 19.0.25.313 (Telerik.Reporting.Cache.StackExchangeRedis)

  Request:
  Add a RedisStorage constructor overload that accepts StackExchange.Redis.IConnectionMultiplexer rather than only the concrete ConnectionMultiplexer.

  Current behavior:
  new RedisStorage(ConnectionMultiplexer connectionMultiplexer) requires the concrete type.

  Problem:
  Modern ASP.NET Core apps manage a single shared multiplexer through DI and expose it as IConnectionMultiplexer — the abstraction recommended by StackExchange.Redis, and the same type
  Microsoft.Extensions.Caching.StackExchangeRedis uses via its ConnectionMultiplexerFactory (which returns IConnectionMultiplexer). To call RedisStorage we are forced to downcast our IConnectionMultiplexer back to
  ConnectionMultiplexer. This is fragile and it prevents passing test doubles or decorators (e.g. for instrumentation/logging).

  Proposed change:
  Add RedisStorage(IConnectionMultiplexer connectionMultiplexer), plus a databaseNumber overload (RedisStorage(IConnectionMultiplexer connectionMultiplexer, int databaseNumber)). ConnectionMultiplexer already
  implements IConnectionMultiplexer, so this is fully backward-compatible — existing callers that pass a concrete instance keep working unchanged. Everything RedisStorage needs is available on the interface
  (GetDatabase for string operations and LockTake/LockRelease, GetSubscriber, GetServer).

  Benefits:
  - Clean dependency-injection integration with a shared, app-managed multiplexer.
  - Unit-testability via a mocked IConnectionMultiplexer.
  - Consistency with StackExchange.Redis guidance and Microsoft's own caching abstractions.

  Note:
  Please target the maintained Telerik.Reporting.Cache.StackExchangeRedis package (the .2 variant appears discontinued after 18.2.24.806 and has no 19.x/20.x release).