Generate OPENJSON with WITH unless ordering is required

[roji]

This PR based based on top of #30976 and #30956, review those first and ignore the first commits here.

We currently generate SQL Server OPENJSON expressions without WITH, applying a regular relational cast to applying the element store type to the output:

WHERE [t].[Id] IN (
    SELECT CAST([i].[value] AS uniqueidentifier) AS [value]
    FROM OPENJSON(@__ids_0) AS [i]

We use this form because it allows preserving the ordering of the JSON array (not needed in the above specific query), and that's not possible with the OPENJSON form that accepts WITH.

This PR switches to using OPENJSON with WITH in contexts where preserving the ordering isn't needed, such as the above query:

WHERE [t].[Id] IN (
    SELECT [i].[value]
    FROM OPENJSON(@__ids_0) WITH ([value] uniqueidentifier '$') AS [i]

Where ordering is important, we continue to use OPENJSON without WITH as today.

Compared to OPENJSON with WITH, OPENJSON without WITH has some performance drawbacks (see #13617 (comment), #13617 (comment)). In addition, some conversions from JSON are only possible when using the WITH variant (see #30727 (comment)).

/cc @yv989c, @pfritschi

[roji]

Converting this back to a draft - there are probably patterns where ordering should be preserved that aren't detected by the current implementation (e.g. projecting out the entire collection as-is, applying an aggregate function that cares about ordering, such as string.Join). It may be a better approach to start with OPENWITH without WITH (and with the ORDER BY), and later convert to the more efficient form (with WITH) only if the ORDER BY has been removed (i.e. as a natural result of the subquery being inside IN/EXISTS).

Ended up starting with OPENJSON/WITH and an ordering by the (non-existing) key; this is an intermediate representation which is temporarily incorrect. In post-processing, a visitor finds SelectExpressions over OPENJSON where the ordering is still there, and removes the WITH (applying a cast on the projection instead). This leverages the existing logic in the query pipeline to elide ordering (e.g. when applying EXISTS/IN): if the ordering gets elided, we simply maintain the original OPENJSON/WITH; if the ordering is still there in post-processing, we convert it.

[roji]

@maumar new version up, rebased on latest main.

I added two tests per your offline comments:

• Column_collection_OrderByDescending_ElementAt applies an ordering to a (naturally ordered) column collection. This shows the natural ordering (by key) getting erased (e.g. x.OrderBy(a).OrderBy(b) removes the first ordering). But it did uncover a small bug in ElementAt, so thanks!
• Inline_collection_Join_ordered_column_collection joins against an ordered collection; here too, the ordering gets elided since the ordering of joined rowsets has no meaning.