Extensions: follow-ups for metadata

[jcouv]

The list includes:

• Add Name property to synthesized attribute Extensions: add Name property on embedded ExtensionMarkerAttribute #80456
• do we need special handling in GetSymbolToLocationMap (scenario related to winobj files)
• Ping known metadata consumers (SandCastle, decompilers, GenAPI tools)
• Test ref-only assemblies (should already work, needs test)
• Test various tagged cases in PENamedTypeSymbol (tracked in source)
• consider adding ExtensionAttribute to extension skeleton types even when no member method (ExtensionGroupingType always has the attribute)
• Metadata: copying attributes (synthesized attributes like nullability? we copy some attributes from enclosing method to closure type, see previous work that implemented that) Extensions: propagate attributes on type parameters #80032
• new metadata design (feature branch)
  • switch away from ordinals in skeleton type names Move to new metadata format for extensions #79553
  • XML doc comments and IDs for merged extension blocks Extensions: update xml docs to new metadata design #79641
  • don't synthesize attribute when already found
  • Detecting and reporting collisions during merge into grouping and marker types. For grouping type: Types from different assemblies will collide, should error. "These things go into the same type, is that appropriate?" Check based on metadata name.
  • Finalizing anything that affects metadata names. Prefixes, etc.
  • Test that the right things are dropped from grouping types. Round-trip ExtensionParameter, Verify IL, ...
  • Test that the right things are preserved on marker types.
  • disallow usage ExtensionMarkerName attribute in source
  • PROTOTYPE comments and skipped tests (linked to this issue)
  • add ExtensionMarkerNameAttribute to BCL (see [API Proposal]: ExtensionMarkerAttribute runtime#118179 and Add ExtensionMarkerAttribute runtime#118188)
  • The grouping and marker types should be among exported types (since they are public) when the enclosing type is among the exported types. Type symbols representing extensions from the language perspective should not be in the set.
  • The grouping and marker types should be among the forwarded types (since they are public) when the enclosing type is forwarded. Type symbols representing extensions from the language perspective should not be in the set.
• confirm on parameter ordinal used in EmitExpression.EmitParameterIdExpression Extensions: address instrumentation follow-ups #79557
• consider adding private constructor to extension skeleton types?
• User may apply attribute to set special name. We should honor that on the implementation method
• Implementation methods should be considered implicitly declared
• Manual testing with reflection

Not blocking shipping:

• consider optimizing lookup using presence of [Extension] attribute
• Consider not emitting any metadata for empty extension blocks
• Skeleton methods should throw NotSupportedException (currently using throw null) Extensions: throw NotSupportedException instead of null #80420

Relates to test plan #76130