SQL Server: consider lax vs. strict in queries (JSON_VALUE/OPENJSON)

When generating JSON_VALUE, we currently don't specify lax/strict, so the query defaults to strict mode ([docs](https://learn.microsoft.com/en-us/sql/t-sql/functions/json-value-transact-sql?view=sql-server-ver17#lax-mode-and-strict-mode)). This has several consequences:

* If the the property being extracted (or any path component) is missing, lax mode returns NULL, whereas strict throws. We generally want to follow System.Text.Json behavior, so returning NULL (lax mode) maybe actually be the bettter option here.
* If the JSON in the database contains a different property type (e.g. string instead of int, object instead of string), lax returns NULL while strict throws. The strict behavior may be better here, as a clear failure is probably better than data corruption (see [#36626](https://github.com/dotnet/efcore/issues/36626)).
* Accessing beyond the endd of an array returns NULL in lax mode, and our null compensation can actually cause data corruption (see [#33784](https://github.com/dotnet/efcore/issues/33784)).

Additional notes:

* Some/most of the above may be relevant for OPENJSON as well.
* There's the related lax vs. strict question in the update pipeline (as opposed to query), considerations are likely different there (see [#33565](https://github.com/dotnet/efcore/issues/33565)).
* Although this issue is for SQL Server, the same issues (and a lax/strict distinction) is present in other databases; look at these as part of this.