Implement JSON serialization/deserialization via Utf8JsonReader/Utf8JsonWriter

[roji]

We currently do JSON serialization/deserialization by passing through DOM. That is, when deserializing, we get a JsonDocument from S.T.Json, and then construct entity CLR types from that (serialization works similarly in the other direction). Instead, we could simply parse the JSON via Utf8JsonReader (which is what JsonSerializer uses under the hood), and directly materialize entity CLR types from that. This should substantially reduce CPU time and heap allocations.

Note that we could use code generation to compile the JSON materializer, just like we do today for regular materialization from DbDataReader. In fact, Utf8jsonreader and DbDataReader are similar, offering the same kind of low-level access to primitive int/string values.

• This technique wouldn't support JsonSerializationOptions - but our current technique is also very limited. When using EF, EF is the one managing the "serialization ones", e.g. assigning names to properties (and even naming conventions), value converters (instead of S.T.Json JsonConverters), etc. Though we should still see if it makes sense to accept and respect certain JsonSerializationOptions settings.
• By default, we DbDataReader.GetString() to get the JSON string to be serialized; that's UTF16 rather than UTF8. It's trivial to transcode and should add very little overhead (compared to the extra DOM processing we do today, in any case). In cases where we can just get UTF8 directly from the database (Npgsql, SQL Server with UTF8 columns), we can skip this step. Note that with Npgsql we can even get a raw binary Stream out of DbDataReader, and pass that to Utf8jsonreader, for maximum perf.
• It should be possible to support unmapped JSON properties by writing them to some structure (possibly a JsonDocument DOM representation) which gets stored in the change tracker, in the entry. In the update pipeline, these unmapped would be written back to the database.

Note: benchmark to see the perf differences

[AndriySvyryd]

Consider caching the JSON property names as JsonEncodedText in a annotation on the property

[roji]

@maumar on the UTF16/UTF8 question (2nd point above)... Utf8JsonReader requires a UTF8 string, represented as a ReadOnlySpan<byte>, but strings for databases are generally exposed as .NET string, which is UTF16.

I think this issue should do the simple/minimal thing, and just transcode the string you get from DbDataReader into a UTF8 byte array on the heap. This isn't the most efficient thing (although most probably still significantly more efficient than the current DOM implementation), but it would work everywhere. Later, as an optimization we can skip that steps for ADO.NET providers where getting a raw UTF8 byte array is supported (Npgsql allows this; SqlClient might, if not we can raise the request).