Deprecate BicepSecretOutput and build a first class AzureKeyVaultSecretReference

[davidfowl]

Today we have BicepSecretOutputReference which was created to represent an output from a bicep file that is a secret. This encapsulates the pattern documented here https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/scenarios-secrets#use-key-vault.

Bicep and ARM now support the concept of secure outputs (Azure/bicep#2163 (comment)) but we want to continue using key vault since it allows us to directly map secrets to environment variables (or it can be read directly by application code).

The big problem today is that BicepSecretOutputReference force constructions of a new key vault per resource, see #4061 for details.

Instead of trying to support this we want to support a new primitive AzureKeyVaultSecretReference. This would solve the above and allow modeling keyvault secrets directly in the app host. For resources that want to write their secrets into keyvault, we need to express that in a more first-class API e.g.

// Declare a key vault to store all secrets
var vault = builder.AddAzureKeyVault("kv");

var redis = builder.AddAzureRedis("redis")
                   .WithAccessKeyAuthentication(vault);

var cosmos = builder.AddAzureCosmos("account")
                    .WithAccessKeyAuthentication(vault)
                    .AddCosmosDatabase("db");

builder.AddProject<Projects.Api>("api")
       .WithReference(redis)
       .WithReference(cosmos);

Redis has a keyvault that can be used to write secrets into. When the project references Redis, that will put an AzureKeyVaultSecretReference as an environment variable in the project. This will be understood as a keyvault secret and resolved appropriately.

This unified approach allows us to start tackling #2587 as it would also work standalone.

This approach also enables an approach where no environment variables are ever used, and secrets are stored in key vault and only ever retrieved in the application.

var vault = builder.AddAzureKeyVault("kv");

var redis = builder.AddAzureRedis("redis")
                   .WithAccessKeyAuthentication(vault);

var cosmos = builder.AddAzureCosmos("account")
                    .WithAccessKeyAuthentication(vault)
                    .AddCosmosDatabase("db");

// The applicaiton reads the connection strings from connectionstrnigs--db and connectionstrings--redis
// using the kv configuration provider
builder.AddProject<Projects.Api>("api")
       .WithReference(kv);

This makes it obvious that KeyVault is being used, and allows the user to control the instances.

[davidfowl]

cc @eerhardt