Stop PG from using a generic plan when an array is parameterized

[roji]

When arrays get parameters (e.g. WHERE b.Foo = ANY ($1)), the cardinality of the array can be very important to choosing the right query plans; see dotnet/efcore#32394 for numerous reports of regressions on SQL Server in 8.0, because of the switch from constants to OPENJSON there.

In PG we didn't have a translation change in 8.0 - the provider always parameterized arrays. However, the same sort of problem (inefficient plans due not taking array cardinality into account) can occur with PG as well; if Npgsql is configured to do auto preparation (which is recommended), then the query SQL may end up getting a generic plan; at that point, the query is stuck with a plan that has some arbitrary array cardinality (based on the first few executions presumably).

We could mitigate this by forcing PG to use custom plans as soon as an array is parameterized. This can be done in two ways:

1. Add some API in NpgsqlCommand which allows users (e.g. EF) to specify that the command shouldn't get auto-prepared; EF would set that when an array is parameterized.
2. Inject SET plan_cache_mode= force_custom_plan (docs) before the query, and RESET plan_cache_mode after (while still batching for a single roundtrip).

(2) still allows using prepared statements - which may help a bit - while (1) doesn't, so we should probably do that...

Thanks to @laurenz and @NinoFloris for the discussions around this (if you have anything to add to the above please comment).