Add FrozenSet.Create collection builder

[stephentoub]

Closes #92190

[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.

[tannergooding]

Not really related to this PR, but with all the improvements around ROSpan<T> (params, the new language support that makes ROSpan<T> the preferred overload, collection expression, etc) do we have any plans to expose constructor overloads on the various collection types so this can just be new(source), much like we could if it had been an IEnumerable<T>?

Seems like a generally good thing that can simplify the patterns for common user scenarios. -- Notable doing HashSet<T> set = [..source]; works as well, its just not super efficient today and looks to go through the enumerator not the special for (...) iteration that span normally gets.

[stephentoub]

We'd like to, but we can't do that well yet. Even with how the current first-class span support is defined, if HashSet gained a HashSet<T>(ReadOnlySpan<T>) overload and you tried to call that with an array, it would fail to compile due to ambiguity, since array can implicitly convert to both IEnumerable<T> and ReadOnlySpan<T>.

This should however resolve itself if/when we make ReadOnlySpan<T> : IEnumerable<T>, as that will result in ReadOnlySpan<T> being considered better for overload resolution. The ref struct work just landed in Roslyn main today. Once that lands in runtime and I can more easily vet it, my plan is to create a proposal for the resulting improvements we should make in .NET 9, including where we want to annotate with allow ref struct (e.g. delegates, enumerable) and what new APIs we can then expose that we've been wanting to (e.g. that ctor on HashSet).

[TonyValenti]

🎉🎉🎉