Mark AzurePublisherOptions as Experimental

[eerhardt]

See #7811 (comment)

Checklist

• Is this feature complete?
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Is this introducing a breaking change?
      • No
        • Link to aspire-docs issue [New article]: Add ASPIREAZURE001 to aspire/diagnostics docs (dotnet/docs-aspire#2882)

[Copilot]

Pull Request Overview

This PR marks the AzurePublisherOptions API as experimental so that consumers are aware its interface and behavior may evolve.

• Added an Experimental attribute to the AzurePublisherOptions class
• Introduced a using directive for System.Diagnostics.CodeAnalysis

[joperezr]

I know this is just following precedent of other experimental attributes, but in hindsight, I wonder if it would've been better to just have these attributes be all ASPIRE0xxx and just increment the number. That seems to be the pattern that some of the other repos using experimental do anyway.

[eerhardt]

@mitchdenny - thoughts on this? I think you set the precedent as you were the first to make experimental APIs.

See Uses new Azure.Provisioning packages which have been split by resource (dotnet/aspire#3383)

9f499db

[joperezr]

Separate from this PR, we should make sure that we are documenting these attributes and that the forward links work. (PS I see you added and linked a docs issue, my comment is just to do a pass for all of these)