Remove System.Text.Json's DynamicDependencies on Collections.Immutable #53256

Today, JsonSerializer takes a DynamicDependency on basically all the System.Collection.Immutable CreateRange methods:

This causes all of the Immutable Collection types to be rooted in an application, even if the app doesn't use the types. This is a fairly substantial amount of code, especially in cases where every KB counts, like Blazor WASM apps.

With #53205, I found out that a bunch of other collection types don't work in JsonSerializer in a trimmed app. That makes me think that these Immutable collection types really shouldn't be treated specially, especially considering they bring in so much unused code.

I prototyped what it would look like removing these DynamicDependencies here. Using this prototype I was able to measure just how much code these DynamicDependencies are causing:

Before: 2,600,754 bytes
After: 2,572,198 bytes

It decreases the app size almost 28KB .br compressed.

With the advent of the JSON source generator, we can make applications that call JsonSerializer trim-safe by telling developers to use the source generator when they need to serialize/deserialize objects. If they care about trim-safety, they can convert their code to use the source generator, and it will work, even after trimming.

However, the problem with removing these attributes is that existing apps that use Immutable Collections in a JSON graph would be broken once they are trimmed. For normal apps, we will give them a warning in all places they call the serializer. However, for Blazor WASM apps, these warnings are suppressed by default. So apps won't see them.

I can think of the following strategies we could take to resolve this:

1. Just remove the DynamicDependencies, and if developers run into issues we tell them to either use the source generator, or tell them which ImmutableCollection methods to root in their app.
2. Introduce a new feature switch, which conditionally adds these DynamicDependencies. By default in Blazor WASM apps, the switch is set to not root these collections. Developers who run into problems in their app can just flip the feature switch, and these collections will be rooted again.
3. Continue down the current path, and if we fix Using Queue, Queue<T>, Stack, and ConcurrentStack<T> as properties in classes deserialized by System.Text.Json does not work when trimmed #53205, JSON will root even more collections that may not even be used in the application.

In my opinion, using Immutable Collections in a JSON graph isn't a super common case. Paying this price in all apps that use JSON isn't worth the tradeoff.

Thoughts?

@steveharter @layomia @eiriktsarpalis @jozkee @vitek-karas @marek-safar @SteveSandersonMS @pranavkm @danroth27 @stephentoub @jkotas