Add CollectionBuilder attribute to some immutable collection interfaces

[stephentoub]

Roslyn asked that these be added. Adding these attributes to the immutable interfaces was discussed as part of #87569 (comment) and left up to the working group to decide what to do with it, which is this PR.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Roslyn asked that these be added. Adding these attributes to the immutable interfaces was discussed as part of #87569 (comment) and left up to the working group to decide what to do with it, which is this PR.

Author:	stephentoub
Assignees:	-
Labels:	area-System.Collections, new-api-needs-documentation
Milestone:	8.0.0

[CyrusNajmabadi]

@cston @RikkiGibson @captainsafia . We shoudl have a meeting to conclude on this. If we do take this path, we will need to ensure the lang spec/impl allows for this. Specifically, where the factory method returns a different (but implicit-reference compatible) result.

[RikkiGibson]

Totally. I don't know whether/how we should limit the permitted implicit conversions. For example, if the implementation type is a struct, is it ok to do a boxing conversion here? The user is applying the attribute. We might assume they know which method is being referenced in the attribute and they're OK with the semantics of converting the result to interface type.

[CyrusNajmabadi]

Totally. I don't know whether/how we should limit the permitted implicit conversions. For example, if the implementation type is a struct, is it ok to do a boxing conversion here? The user is applying the attribute. We might assume they know which method is being referenced in the attribute and they're OK with the semantics of converting the result to interface type.

My presumptino is that at least an implicit conversion needs to exist.

1. i don't believe we need to validate that form them at the declaration site.
2. at teh use site, i think we should just treat this like assignment and only allow if hte assignment is allowed. we can report an error if not (either that no compatible method was found, or specifically that hte return type has no viable conversion).

In practice, i expect usage to be exactly like this. There is a concrete type returned and it has an implicit conversion (ideally reference, but any implicit seems fine) to the interface. I think boxing is fine as i could totally see a lightweight struct being an impl for some types, and the interface just going: yup, good enough for me.

[stephentoub]

C# 12 is going to support the conversion.