Allow users to define EmbeddedAttribute

[333fred]

Alternative approach to #71546. Today, our enforcement of whether to allow users to define Microsoft.CodeAnalysis.EmbeddedAttribute is inconsistent; if we need to generate it, we error if the user defines one. But if the we don't need to generate it (as we increasingly do not since .NET 6), we allow the user to define their own version. This PR standardizes our enforcement, and enables the compiler to use the user-declared attribute instead generating one. We also document the breaking change from the standardized enforcement.

[333fred]

@dotnet/roslyn-compiler for review. I'll propose a source-generation API to allow authors to create this API easily, but this change can go in separately. For VB, there are existing tests verifying that it respects the EmbeddedAttribute definition, and allows defining in the same assembly. I opted not to enforce any shape on the VB as it doesn't do any form of validation in any scenario for the attribute definition today. We now validate the VB side, because we will synthesize an EmbeddedAttribute application for the type. This has also been documented as a breaking change.

[AlekseyTs]

Done with review pass (commit 8) #Closed

[333fred]

@AlekseyTs I believe I've address your feedback, thanks!

[jjonescz]

Unrelated to the PR: it's not clear to me what the Microsoft.CodeAnalysis.EmbeddedAttribute does. Is that documented somewhere?

[333fred]

Not documented afaik, though we will when we add the SG API. It prevents the compiler from resolving the type outside the current compilation. It's how the compiler itself gets around the "type defined in multiple assemblies" issues when it needs to synthesize an attribute.

[333fred]

@AlekseyTs addressed feedback, thanks!

[AlekseyTs]

Done with review pass (commit 11) #Closed

[333fred]

@AlekseyTs @cston for another review pass

[AlekseyTs]

LGTM (commit 12)