Add JsonSerializerOptions.MakeReadOnly(bool) overload.

[eiriktsarpalis]

Fix #89934.

cc @halter73 @eerhardt

[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-text-json, @gregsdennis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fix #89934.

cc @halter73 @eerhardt

Author:	eiriktsarpalis
Assignees:	-
Labels:	area-System.Text.Json, new-api-needs-documentation
Milestone:	-

[eerhardt]

ConfigureForJsonSerializer() will throw an exception when JsonSerializer.IsReflectionEnabledByDefault == false && TypeInfoResolver == null saying:

Reflection-based serialization has been disabled for this application. Either use the source generator APIs or explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property.

I don't think ASP.NET Core will be able to use this new API because of this. There are scenarios where we need to call MakeReadOnly() on a JsonSerializerOptions that doesn't have its TypeInfoResolver set yet. One example is in MVC:

dotnet/aspnetcore#49360

MVC always creates a SystemTextJsonOutputFormatter up front without knowing if the app is actually going to use JSON serialization or not. When the app doesn't touch JSON, we shouldn't be throwing an exception at startup.

[eiriktsarpalis]

It looks like aspnetcore was able to work around #89830 since it owns its JsonSerializerOptions instances, so we don't need new APIs to unblock that case.

The semantics of the new overload is oriented towards components accepting JsonSerializerOptions instances they don't own but still need to emulate the behavior of the JsonSerializer methods.