Automatically persist generated password for all containers with user names and passwords

[DamianEdwards]

By default today, we auto-generate a password for the SQL Server container when AddSqlServerContainer is called in an AppHost project. A random password on each app start isn't a great experience though as anything created in one session cannot be used in the next if a persistent volume is configured.

We should consider how we might instead automatically manage preservation of the generated password and reuse in subsequent runs, e.g. in user secrets. One challenge of user secrets is it requires initializing the project with an ID (via an MSBuild property in the project file) and modifying the project file while the app is running is probably not a great idea.

[mitchdenny]

@DamianEdwards I've got this PR where I am looking to add secret support to Aspire:

#1487

This PR is the first phase which adds the underlying resource types, but in the comments I've added a note on how this could evolve to provide some increased management around managing container password secrets (as an example). The difference here is that we don't store a generated password, instead we get a password from configuration (locally) which could be in user secrets.

I think that this is a reasonable pay for play compromise? Even if we did want to go further and do generation and storage we'd probably layer it on top of this generic secrets mechanism rather than building it bespoke for each resource?

[mitchdenny]

Punting to preview 4 because we won't have time to react to some of the discussions from our app model offsite and it will dictate what we do here.

[mitchdenny]

We discussed this at one of the AppHost syncs. We still want to do this an it's an important building block for container persistence.

[davidfowl]

Related to #2438

[davidfowl]

Putting this in 8.1. It's important for the volume experience.

[davidfowl]

Sweet!