ResponseCachingMiddleware is too restrictive – IResponseCachingKeyProvider and IResponseCache should be public

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

When using ResponseCachingMiddleware, I encountered several limitations that make it difficult to extend or optimize its behavior:

1) Custom Key Provider is not possible
IResponseCachingKeyProvider is internal, so I cannot modify the key generation logic.
I need to use a hashed key (XxHash128 with a fixed key) for security reasons (storing encrypted cache keys).
This also allows optimizations with stackalloc and enables distributed caching with Redis.

2) Cannot invalidate cache manually
IResponseCache is internal, which means there is no public API to invalidate cache entries.
I need to forcefully remove cache entries when an event occurs in my system without waiting for TTL expiration.

3) No reusable CachedResponse API
CachedResponse has useful functionality for copying HttpContext, but it is not encapsulated in a reusable service.
If I want to implement custom caching logic, I have to copy existing internal code, which is not ideal.

### Describe the solution you'd like

1) Make IResponseCachingKeyProvider and IResponseCache public
This allows for custom implementations of key providers and caching mechanisms.

2) Extract caching logic from ResponseCachingMiddleware into a separate service
This makes caching logic more modular and reusable.
Improves testability and makes it easier to integrate with other storage solutions (e.g., Redis, distributed caching).

3) Optimize the implementation
If the proposal is accepted, I can submit a PR that includes modern optimizations such as Span usage where applicable.

### Additional context

If this approach makes sense, I would be happy to implement the necessary changes and submit a PR.

Start at ResponseCachingMiddleware and inspect the internal IResponseCachingKeyProvider, IResponseCache, and CachedResponse APIs. Determine how the requested public interfaces, reusable caching service, manual invalidation, and custom key generation fit together; done means the agreed API and extraction are implemented with coverage for the existing behavior.

Written by the indexing model from the issue text.