Fixes and cleanup around JSON collection SQL value conversions

[roji]

This does work around SQL logic for converting values out of JSON so they can be further queried in SQL. Originally I thought we may want to add a general API on the type mappings, but I don't think that makes sense at this point. The conversions needed for SQLite are concentrated in a single simple method, and there's no real value in refactoring that out to the type mappings (SQL Server doesn't need any). We can always change this in the future, but for now I think we should leave this as an internal implementation detail of each provider.

The update pipeline doesn't need to perform server-side conversions to JSON; we simply generate the JSON representation we want client-side, and send the appropriate parameter for that (e.g. a JSON string representation of a timestamp). An alternative approach would be to e.g. send a regular DateTime parameter, and then use SQL to convert that to the JSON string representation. But there's no real advantage in that, and it's complex/not always possible. I've done some cleanup/improvement to partial updating in #31232, but I don't think anything else is needed at this point.

(Note that if we ever want to allow a JSON property to be a key/concurrency token, the update pipeline would need to apply the same conversions as the query pipeline (because it would need to appear in the UPDATE WHERE clause)

Specific notes on what's converted and what's not supported:

• On SQL Server, no SQL conversions are needed.
  • When using OPENJSON with WITH (no ordering preservation), it does the conversion job just fine.
  • When using OPENJSON without WITH (because order needs to be preserved), we add SQL CAST() to convert the JSON value out; this works fine in all cases except for varbinary, since CAST() doesn't handle base64. So varbinary is specifically unsupported in scenarios which require ordering preservation.
• On SQLite:
  • We apply special conversions for DateTime (apply datetime() to remove the T) and Guid (uppercase)
  • Decimal, binary and DateTimeOffset are not supported, because there doesn't seem to be a good way to convert them out of JSON.

Related to #30727

[maumar]

maybe we need list of test names to exempt from Check_all_tests_overridden?

[roji]

We could, though I think it's not too bad like this... It even makes me explicitly see that we're not really overriding, i.e. that for byte arrays we assert failure in the base etc.

[roji]

Pay special attention to SQLite Array_of_TimeOnly after #31272 is merged (https://github.com/dotnet/efcore/pull/31272/files#r1264439804 after that's merged)