Add Aspire.Microsoft.Azure.StackExchangeRedis component for Azure Cache for Redis with Azure AD authentication

[Copilot]

• Create Aspire.Microsoft.Azure.StackExchangeRedis component with core functionality
• Complete component implementation with tests
• Remove PackageIconFullPath from csproj file
• Remove EnablePackageValidation from csproj file
• Make AzureStackExchangeRedisSettings inherit from StackExchangeRedisSettings instead of duplicating properties (changed to composition due to sealed class)
• Update extensions to use same config section as base Redis component
• Follow Azure Npgsql pattern for configuration and authentication setup
• Update all test files to use correct configuration section name
• Remove unnecessary ConfigurationSchema.json file since using base component's schema
• Build and test the changes

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[davidfowl]

@copilot address the review feedback

[Copilot]

@copilot address the review feedback

Addressed all the review feedback in commit efb458c:

• Removed PackageIconFullPath and EnablePackageValidation from csproj
• Updated AzureStackExchangeRedisSettings to use composition with only the Credential property
• Changed to use the same config section as base Redis component
• Followed Azure Npgsql pattern for delegating to base component methods
• Updated all tests and removed duplicate configuration schema

[github-actions]

🚀 Dogfood this PR with:

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 11141

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 11141"

[eerhardt]

@sebastienros @davidfowl @DamianEdwards @mitchdenny - I think this is a better composability API in general.

• The core AddRedisClientBuilder API adds the core IConnectionMultiplexer to DI (you can pick keyed or unkeyed).
• The extension methods build on that core multiplexer - adding Azure auth (or other auth in the future), Distributed caching, Output caching, etc.

I think this API shape makes much more sense than what we have today. It allows for picking which things are keyed and which aren't. For example, I can have a keyed core Redis connection, but an unkeyed DistributedCache. And vice versa.

Let me know what you think of this API shape. I think this is the route I want to go to make Redis Azure + Distributed/Output caching composable.