AzureProvisioner output saves connection strings to user secrets even if it did nothing

[davidfowl]

This is what happens when you use an azure resource and do nothing else:

Building...
info: Aspire.Hosting.Azure.AzureProvisioner[0]
      Using DefaultAzureCredential for provisioning. This may not work in all environments. See https://aka.ms/azsdk/net/identity/default-azure-credential for more information.
info: Aspire.Hosting.Azure.AzureProvisioner[0]
      Azure resource connection strings saved to user secrets.

The first log should only show up if we are going to provision.
The second log should only show up if we have indeed saved connection string to user secrets.

[scabana]

I don't want to open another issue about AzureProvisioner and user secrets. I have a feeling a provisioner api would help with those issues.

The way it's coded, anyone taking the AzureProvisioner as an example to have a custom provisioner could encounter a concurrency issue updating the user secrets. As the provisioner loads the user secrets once and then saves it at the end of the work (which is launched in Task.Run). Another provisioner that would do the same could end up losing / overriding modified user secrets from another provisioner.