Add type mapping APIs to customize JSON value serialization/deserialization

[roji]

When reading and writing JSON documents, we need to control the precise conversion from a .NET value to a JSON element, to be integrated in the larger JSON document. This is somewhat similar to GenerateNonNullSqlLiteral, but for values inside JSON. In simple cases (int, string), no special logic is needed; but in certain cases, we need to precisely control the representation. For example, a NetTopologySuite Geometry would likely need to be serialized as WKT, which isn't necessarily what ToString returns.

Note the interaction between this issue and #30604, which is about switching to the lower-level Utf8JsonReader/Utf8JsonWriter APIs rather than passing through DOM. If/when we do that, the type mappings would be the ones calling specific APIs e.g. on Utf8JsonWriter.

In addition to serialization/deserialization, we also need a hook for perform a SQL conversion from the JSON (text) value to the actual store type; this is needed when extracting a value from a JSON document and e.g. comparing them to a regular database column. For example, the JSON representation of a timestamp is ISO8601 (with a T), but in SQLite, a timestamp is typically represented as a timestamp text without the T (and so datetime() must be invoked). Similarly, to convert a geometry WKT representation to an actual SQL Server geometry type, a function to parse the WKT needs to be invoked. Moving the server-side conversion part to #30727.

Tests affected:

• NorthwindJoinQueryTestBase.Join_local_string_closure_is_cached_correctly (string treated as enumerable of chars)
• NorthwindJoinQueryTestBase.Join_local_bytes_closure_is_cached_correctly (same)

[AndriySvyryd]

Consider using an abstraction that doesn't depend on a particular implementation, see CosmosSerializer.
For example, CoreTypeMapping could have T FromJson<T>(Stream) and void ToJson<T>(T, Stream) (and async versions) that would only need work for a T supported by a given type mapping and would instantiate (without allocating) a Utf8JsonReader/Utf8JsonWriter in the implementation.
To replace the underlying serializer a provider-specific ITypeMappingSourcePlugin implementation could be used (#28043)

The base implementation could call JsonSerializer.Serialize/Deserialize

We could allow JsonReaderOptions and JsonWriterOptions or a custom type in context options to control the default implementation.

[AndriySvyryd]

Looking into this a bit more I don't think it's possible to create a performant abstraction that would allow to replace the implementation without massive amounts of code.

Some things to consider:

• We can't control in what order the properties will come out of the query, so we can't get the correct type mapping until we read the property name.
• When reading from a stream we need a callback to increase the buffer size in case a token doesn't fit.

So here's another proposal:

• T FromJson<T>(ref Utf8JsonReader, Action<bool>?)
• void ToJson<T>(Utf8JsonWriter, T)

For the server-side conversion consider #30729.