React to attribute centralization

[333fred]

dotnet/runtime#85612 plans to centralize the locations of attributes defined by the C# compiler into corelib as public types to reduce duplicate definitions. As part of that, we'll need to react and validate scenarios:

• Does the issue have the full list of attributes currently synthesized by Roslyn? (cataloged in Attribute definitions included in assemblies using Nullable on the latest framework runtime#85612 (comment))
• What order do we lookup existing attribute definitions? Likely we need to prioritize attributes coming from corlib, meaning coming from the assembly that defines System.Object and has no references.
• What is the compiler's behavior when it sees these attributes via an assembly reference it has IVT to today? If that assembly is recompiled with these new definitions and grants IVTs, does it need to include type forward attributes to keep things working?

/cc @jaredpar for anything I'm missing in this list.

[333fred]

I've done some investigation into the current state of these attributes, and thankfully our past selves planned for this type of thing. When we synthesize attributes today, we put an EmbeddedAttribute on those synthesized definitions, preventing any downstream assemblies from consuming them, even with IVTs. We already prioritize WellKnownType definitions in corelib today, so we don't need any behavior changes there, and so long as we continue to put EmbeddedAttribute on synthesized definitions, we should be fine in the future. Users that manually polyfill attributes will need make sure to type forward on platforms that contain the attributes to prevent binary breaks, but that is already true today, and manual polyfilling is not silent to the user doing it.

TLDR; there is nothing for us to react to.